draft-ietf-mile-rolie-01.txt   draft-ietf-mile-rolie-02.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft Pivotal Internet-Draft Pivotal
Intended status: Informational December 2, 2015 Intended status: Informational S. Banghart
Expires: June 4, 2016 Expires: December 5, 2016 NIST
June 3, 2016
Resource-Oriented Lightweight Indicator Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-01 draft-ietf-mile-rolie-02
Abstract Abstract
This document defines a resource-oriented approach to cyber security This document defines a resource-oriented approach to cyber security
information sharing. Using this approach, a CSIRT or other information sharing. Using this approach, operators may share and
stakeholder may share and exchange representations of cyber security exchange representations of cyber security incidents, attack
incidents, indicators, and other related information as Web- indicators, software vulnerabilities, and other related information
addressable resources. The transport protocol binding is specified as Web-addressable resources. Furthermore, consumers and other
as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of stakeholders may access and search this security content as needed,
link relation types specific to cyber security information sharing is establishing a rapid and on-demand information exchange network for
defined. The resource representations leverage the existing IODEF restricted internal use or public access repositories. This
[RFC5070] and RID [RFC6545] specifications as appropriate. specification builds on and extends the Atom Publishing Protocol and
Coexistence with deployments that conform to existing specifications Atom Syndication Format to transport and share cyber security
including RID [RFC6545] and Transport of Real-time Inter-network resource representations. This document leverages the existing
Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via representations IODEF and RID where appropriate, and supports related
appropriate use of HTTP status codes. cyber security representation standards.
Contributing to this document
The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at
<https://github.com/CISecurity/ROLIE>. Instructions are on that page
as well. Editorial changes can be managed in GitHub, but any
substantial issues need to be discussed on the MILE mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2016.
This Internet-Draft will expire on June 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background and Motivation . . . . . . . . . . . . . . . . . . 4 3. Background and Motivation . . . . . . . . . . . . . . . . . . 4
3.1. Message-oriented versus Resource-oriented Architecture . 5 3.1. Message-oriented versus Resource-oriented Architecture . 5
3.1.1. Message-oriented Architecture . . . . . . . . . . . . 5 3.1.1. Message-oriented Architecture . . . . . . . . . . . . 5
3.1.2. Resource-Oriented Architecture . . . . . . . . . . . 5 3.1.2. Resource-Oriented Architecture . . . . . . . . . . . 6
3.2. Authentication of Users . . . . . . . . . . . . . . . . . 7 4. Atom Publication Protocol and Atom Syndication Format TODO . 7
3.3. Authorization Policy Enforcement . . . . . . . . . . . . 7 5. Normative Requirements TODO . . . . . . . . . . . . . . . . . 8
3.3.1. Enforcement at Destination System . . . . . . . . . . 8 5.1. Atom Requirements . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Enforcement at Source System . . . . . . . . . . . . 9 5.2. Transport Layer Security . . . . . . . . . . . . . . . . 8
4. RESTful Usage Model . . . . . . . . . . . . . . . . . . . . . 9 5.3. Archiving and Paging . . . . . . . . . . . . . . . . . . 8
4.1. Dynamic Service Discovery versus Static URL Template . . 10 5.4. Expectation and Impact Classes . . . . . . . . . . . . . 8
4.2. Non-Normative Examples . . . . . . . . . . . . . . . . . 11 5.5. User Authentication . . . . . . . . . . . . . . . . . . . 9
4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 11 5.6. User Authorization . . . . . . . . . . . . . . . . . . . 9
4.2.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . 14 5.7. Content Model . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . 16 5.8. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Use of Link Relations . . . . . . . . . . . . . . . . 19 5.9. Service Discovery . . . . . . . . . . . . . . . . . . . . 11
5. Requirements for RESTful (Atom+xml) Binding . . . . . . . . . 29 5.9.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 11
5.1. Transport Layer Security . . . . . . . . . . . . . . . . 29 5.9.2. Collections . . . . . . . . . . . . . . . . . . . . . 11
5.2. Archiving and Paging . . . . . . . . . . . . . . . . . . 29 5.9.3. Service Document Security . . . . . . . . . . . . . . 11
5.3. Expectation and Impact Classes . . . . . . . . . . . . . 30 5.10. Category Mapping . . . . . . . . . . . . . . . . . . . . 11
5.4. User Authentication . . . . . . . . . . . . . . . . . . . 30 5.10.1. Collection Category . . . . . . . . . . . . . . . . 12
5.5. User Authorization . . . . . . . . . . . . . . . . . . . 30 5.10.2. Entry Category . . . . . . . . . . . . . . . . . . . 12
5.6. Content Model . . . . . . . . . . . . . . . . . . . . . . 31 5.11. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 12
5.7. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 31 5.12. Entry Content . . . . . . . . . . . . . . . . . . . . . . 13
5.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 32 5.13. Link Relations . . . . . . . . . . . . . . . . . . . . . 13
5.8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 32 5.13.1. Additional Link Relation Requirements . . . . . . . 15
5.8.2. Collections . . . . . . . . . . . . . . . . . . . . . 32 5.14. Member Entry Forward Security . . . . . . . . . . . . . . 15
5.8.3. Service Document Security . . . . . . . . . . . . . . 33 5.15. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 16
5.9. Category Mapping . . . . . . . . . . . . . . . . . . . . 33 5.16. Search . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.9.1. Collection Category . . . . . . . . . . . . . . . . . 33 5.17. / (forward slash) Resource URL . . . . . . . . . . . . . 16
5.9.2. Entry Category . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations TODO . . . . . . . . . . . . . . . . 17
5.10. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations TODO . . . . . . . . . . . . . . . . . . 19
5.11. Entry Content . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
5.12. Link Relations . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12.1. Additional Link Relation Requirements . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
5.13. Member Entry Forward Security . . . . . . . . . . . . . . 36 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.14. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 21
5.15. Search . . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
5.16. / (forward slash) Resource URL . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 42
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 43
Appendix B. Resource Authorization Model . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines a resource-oriented approach to cyber security This document defines a resource-oriented approach to cyber security
information sharing that follows the REST (Architectural Styles and t information sharing that follows the REST (Architectural Styles and t
he Design of Network-based Software Architectures) architectural he Design of Network-based Software Architectures) architectural
style. The resource representations leverage the existing IODEF style. In this approach, cyber security resources are maintained in
[RFC5070] and RID [RFC6545] specifications as appropriate. The web-accessible repositories structured as Atom Syndication Format
transport protocol binding is specified as HTTP(S) with a media type [RFC4287] feeds. Representations of content are categorized and
of Atom+XML. An appropriate set of link relation types specific to organized into indexed collections, which are requested by the
cyber security information sharing is defined. Using this approach, consumer. As the set of resource collections are forward facing, the
a CSIRT or other stakeholder may exchange cyber security incident consumer may search all available content for which they are
and/or indicator information as Web-addressable resources. authorized to view and request that which is desired. Granular
authentication and access controls permit only authorized consumers
the ability to view, read, or write to a given feed. This approach
is in contrast to, and meant to improve on, the traditional point-to-
point messaging system, in which consumers must request individual
pieces of information from a server following a triggering event.
This traditional approach creates a closed system of information
sharing that encourages duplication of efforts and hinders automated
cyber security systems.
The goal of this specification is to define a loosely-coupled, agile The goal of this document is to define the RESTful approach to cyber
approach to cyber security situational awareness. This approach has security communication with the intent of increasing communication
architectural advantages for some use case scenarios, such as when a and sharing of incident reports, vulnerability assessments, and other
CSIRT or other stakeholder is required to share cyber security security content between producers, operators, and consumers.
information broadly (e.g., at internet scale), or when an information
sharing consortium requires support for asymmetric interactions In order to exchange information as web-addressable resources, the
amongst their stakeholders. resource representations leverage the existing IODEF [RFC5070] and
RID [RFC6545] specifications and other representation standards as
appropriate. The transport protocol binding is specified as HTTP(S)
with a media type of Atom+XML. An appropriate set of link relation
types specific to cyber security information sharing is defined.
Coexistence with deployments that conform to existing specifications Coexistence with deployments that conform to existing specifications
including RID [RFC6545] and Transport of Real-time Inter-network including RID [RFC6545] and Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via
appropriate use of HTTP status codes. appropriate use of HTTP status codes.
2. Terminology 2. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Definitions for some of the common computer security-related Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of terminology used in this document can be found in Section 2 of
[RFC5070]. [RFC5070].
3. Background and Motivation 3. Background and Motivation
It is well known that Internet security threats are evolving ever It is well known that the field of threats to computer security is
more rapidly, and are becoming ever more sophisticated than before. evolving ever more rapidly as time goes on. As software increases in
The threat actors are frequently distributed and are not constrained complexity, the number of vulnerabilities in our systems and networks
to operating within a fixed, closed consortium. The technical skills increase exponentially. Threat actors looking to exploit these
needed to perform effective analysis of a security incident, or to vulnerabilities are making more frequent and more widely distributed
even recognize an indicator of compromise are already specialized and attacks across a large variety of systems. The adoption of liberal
relatively scarce. As threats continue to evolve, even an information sharing amongst attackers creates a window of as little
established network of CSIRT may find that it does not always have as a few hours between the discovery of a vulnerability and attacks
all of the skills and knowledge required to immediately identify and on the vulnerable system. As the skills and knowledge required to
respond to every new incident. Effective identification of and identify and combat these attacks become more and more specialized,
response to a sophisticated, multi-stage attack frequently depends even a well established and secure system may find itself unable to
upon cooperation and collaboration, not only amongst the defending quickly respond to an incident. Effective identification of and
CSIRTs, but also amongst other stakeholders, including, potentially, response to a sophisticated attack requires open cooperation and
individual end users. collaboration between defending operators, software vendors, and even
end-users.
Existing approaches to cyber security information sharing are based Existing approaches to cyber security information sharing are based
upon message exchange patterns that are point-to-point, and event- upon message exchange patterns that are point-to-point, and event-
driven. Sometimes, information that may be useful to, and sharable driven. Sometimes, information that may be useful to, and sharable
with multiple peers is only made available to peers after they have with multiple peers is only made available to peers after they have
specifically requested it. Unfortunately, a sharing peer may not specifically requested it. Unfortunately, a sharing peer may not
know, a priori, what information to request from another peer. know, a priori, what information to request from another peer.
Sending unsolicited RID reports does provide a mechanism for Sending unsolicited RID reports does provide a mechanism for
alerting, however these reports are again sent point-to-point, and alerting, however these reports are again sent point-to-point, and
must be reviewed for relevance and then prioritized for action by the must be reviewed for relevance and then prioritized for action by the
recipient. Thus, distribution of some relevant incident and recipient. Thus, distribution of some relevant incident and
indicator information may exhibit significant latency. indicator information may exhibit significant latency.
In order to appropriately combat the evolving threats, the defending In order to adequately combat the evolving threats, computer security
CSIRTs should be enabled to operate in a more agile manner, sharing resource producers should be enabled to share selected information
selected cyber security information proactively, if and as proactively as appropriate. Proactive sharing greatly aids knowledge
appropriate. dissemination as well as improving on response times and usability.
For example, a CSIRT analyst would benefit by having the ability to For example, a cyber security analyst would benefit by having the
search a comprehensive collection of indicators that has been ability to search a comprehensive collection of attack indicators
published by a government agency, or by another member of a sharing that have been published by a government agency, or by another member
consortium. The representation of each indicator may include links of a sharing consortium. The representation of each indicator may
to the related resources, enabling an appropriately authenticated and include links to the related resources, enabling an appropriately
authorized analyst to freely navigate the information space of authenticated and authorized analyst to freely navigate the
indicators, incidents, and other cyber security domain concepts, as information space of indicators, incidents, vulnerabilities, and
needed. In general, a more Web-centric sharing approach will enable other cyber security domain concepts, as needed. In general, a more
a more dynamic and agile collaboration amongst a broader, and varying Web-centric sharing approach will enable a more dynamic and agile
constituency. collaboration amongst a broader, and varying constituency.
The following sections discuss additional specific technical issues The following sections discuss additional specific technical issues
that motivate the development of an alternative approach. that motivate the development of an alternative approach.
3.1. Message-oriented versus Resource-oriented Architecture 3.1. Message-oriented versus Resource-oriented Architecture
The existing approaches to cyber security information sharing are The existing approaches to cyber security information sharing are
based upon message-oriented interactions. The following paragraphs based upon message-oriented interactions. The following paragraphs
explore some of the architectural constraints associated with explore some of the architectural constraints associated with
message-oriented interactions and consider the relative merits of an message-oriented interactions and consider the relative merits of an
alternative model based on a Resource-oriented architecture for use alternative model based on a Resource-oriented architecture for use
in some use case scenarios. in some use case scenarios.
ROLIE specifies a resource-oriented architecture.
3.1.1. Message-oriented Architecture 3.1.1. Message-oriented Architecture
In general, message-based integration architectures may be based upon In general, message-based integration architectures may be based upon
either an RPC-style or a document-style binding. The message types either an RPC-style or a document-style binding. The message types
defined by RID represent an example of an RPC-style request. This defined by RID represent an example of an RPC-style request. This
approach imposes implied requirements for conversational state approach imposes implied requirements for conversational state
management on both of the communicating RID endpoint(s). Experience management on both of the communicating RID endpoint(s). Experience
has shown that this state management frequently becomes the limiting has shown that this state management frequently becomes the limiting
factor with respect to the runtime scalability of an RPC-style factor with respect to the runtime scalability of an RPC-style
architecture. architecture.
In addition, the practical scalability of a peer-to-peer message- In addition, the practical scalability of a peer-to-peer message-
based approach will be limited by the administrative procedures based approach will be limited by the administrative procedures
required to manage O(N^2) trust relationships and at least O(N) required to manage O(N^2) trust relationships and at least O(N)
policy groups. policy groups.
As long as the number of CSIRTs participating in an information As long as the number of participating entities in an information
sharing consortium is limited to a relatively smaller number of nodes sharing consortium is limited to a relatively small number of nodes
(i.e., O(2^N), where N < 5), these scalability constraints may not (i.e., O(2^N), where N < 5), these scalability constraints may not
represent a critical concern. However, when there is a requirement represent a critical concern. However, when there is a requirement
to support a significantly larger number of participating peers, a to support a significantly larger number of participating peers, a
different architectural approach will be required. One alternative different architectural approach will be required. One alternative
to the message-based approach that has demonstrated scalability is to the message-based approach that has demonstrated scalability is
the REST [REST] architectural style. the REST [REST] architectural style.
3.1.2. Resource-Oriented Architecture 3.1.2. Resource-Oriented Architecture
Applying the REST architectural style to the problem domain of cyber Applying the REST architectural style to the problem domain of cyber
security information sharing would take the approach of exposing security information sharing would take the approach of exposing
incidents, indicators, and any other relevant types as simple Web- incidents, indicators, and any other relevant types as simple Web-
addressable resources. By using this approach, a CSIRT or other addressable resources. By using this approach, an organization can
organization can more quickly and easily share relevant incident and more quickly and easily share relevant incident and indicator
indicator information with a much larger and potentially more diverse information with a much larger and potentially more diverse
constituency. A client may leverage virtually any available HTTP constituency. A consumer may leverage virtually any available HTTP
user agent in order to make requests of the service provider. This user agent in order to make requests of the service provider. This
improved ease of use could enable more rapid adoption and broader improved ease of use could enable more rapid adoption and broader
participation, thereby improving security for everyone. participation, thereby improving security for everyone.
A key interoperability aspect of any RESTful Web service will be the A key interoperability aspect of any RESTful Web service will be the
choices regarding the available resource representations. For choices regarding the available resource representations. For
example, clients may request that a given resource representation be example, clients may request that a given resource representation be
returned as either XML or JSON. In order to enable back- returned as either XML or JSON. In order to enable back-
compatibility and interoperability with existing CSIRT compatibility and interoperability with existing implementations,
implementations, IODEF [RFC5070] is specified for this transport IODEF [RFC5070] is specified for this transport binding as a
binding as a mandatory to implement (MTI) data representation for mandatory to implement (MTI) data representation for incident and
incident and indicator resources. In addition to the REQUIRED indicator resources. In addition to the REQUIRED representation, an
representation, an implementation MAY support additional implementation MAY support additional representations if and as
representations if and as needed such as IODEF extensions, the RID needed such as IODEF extensions, the RID schema, or other schemas.
schema, or other schemas. For example, an implementation may choose For example, an implementation may choose to provide support for
to provide support for returning a JSON representation of an incident returning a JSON representation of an incident resource.
resource.
Finally, an important principle of the REST architectural style is Finally, an important principle of the REST architectural style is
the use of hypertext links as the embodiment of application state the use of hypertext links as the embodiment of application state
(HATEOAS). Rather than the server maintaining conversational state (HATEOAS). Rather than the server maintaining conversational state
for each client context, the server will instead include a suitable for each client context, the server will instead include a suitable
set of hyperlinks in the resource representation that is returned to set of hyperlinks in the resource representation that is returned to
the client. In this way, the server remains stateless with respect the client. In this way, the server remains stateless with respect
to a series of client requests. The included hyperlinks provide the to a series of client requests. The included hyperlinks provide the
client with a specific set of permitted state transitions. Using client with a specific set of permitted state transitions. Using
these links the client may perform an operation, such as updating or these links the client may perform an operation, such as updating or
skipping to change at page 6, line 45 skipping to change at page 7, line 10
This document specifies the use of Atom Syndication Format [RFC4287] This document specifies the use of Atom Syndication Format [RFC4287]
and Atom Publishing Protocol [RFC5023] as the mechanism for and Atom Publishing Protocol [RFC5023] as the mechanism for
representing the required hypertext links. representing the required hypertext links.
3.1.2.1. A Resource-Oriented Use Case: "Mashup" 3.1.2.1. A Resource-Oriented Use Case: "Mashup"
In this section we consider a non-normative example use case scenario In this section we consider a non-normative example use case scenario
for creating a cyber security "mashup". for creating a cyber security "mashup".
Any CSIRT can enable any authenticated and authorized client that is Any operator can authorize any or all members of the sharing
a member of the sharing community to quickly and easily navigate community to quickly and easily navigate through any of the cyber
through any of the cyber security information that that provider is security information that that provider is willing to share. An
willing to share. An authenticated and authorized analyst may then analyst may then make HTTP(S) requests to collect vulnerability
make HTTP(S) requests to collect incident and indicator information information known at one producer and threat actor data being made
known at one CSIRT with threat actor data being made available from available from another producer. The resulting correlations may
another CSIRT. The resulting correlations may yield new insights yield new insights that enable a more timely and effective defensive
that enable a more timely and effective defensive response. Of response. Of course, this report may, in turn, be made available to
course, this report may, in turn, be made available to others as a others as a new Web-addressable resource, reachable via another URL.
new Web-addressable resource, reachable via another URL. By By employing the RESTful Web service approach the effectiveness of
employing the RESTful Web service approach the effectiveness of the the collaboration amongst a consortium of cyber security stakeholders
collaboration amongst a consortium of CSIRTs and their stakeholders
can be greatly improved. can be greatly improved.
3.2. Authentication of Users 4. Atom Publication Protocol and Atom Syndication Format TODO
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.
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.
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.
3.3. Authorization Policy Enforcement
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.
3.3.1. Enforcement at Destination System
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.
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.
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.
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.
3.3.2. Enforcement at Source System
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.
Consistent with HTTP [RFC2616] 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.
4. RESTful Usage Model
This section describes the basic use of Atom Syndication Format
[RFC4287] and Atom Publishing Protocol [RFC5023] as a RESTful
transport binding and dynamic discovery protocol, respectively, for
cyber security information sharing.
As described in Atom Publishing Protocol [RFC5023], an Atom Service As described in Atom Publishing Protocol [RFC5023], an Atom Service
Document is an XML-based document format that allows a client to Document is an XML-based document format that allows a client to
dynamically discover the collections provided by a publisher. dynamically discover the collections provided by a publisher.
As described in Atom Syndication Format [RFC4287], Atom is an XML- As described in Atom Syndication Format [RFC4287], Atom is an XML-
based document format that describes lists of related information based document format that describes lists of related information
items known as collections, or "feeds". Each feed document contains items known as collections, or "feeds". Each feed document contains
a collection of zero or more related information items called "member a collection of zero or more related information items called "member
entries" or "entries". entries" or "entries".
skipping to change at page 10, line 12 skipping to change at page 7, line 46
sharing, an Atom feed may be used to represent any meaningful sharing, an Atom feed may be used to represent any meaningful
collection of information resources such as a set of incidents, or collection of information resources such as a set of incidents, or
indicators. Each entry in a feed could then represent an individual indicators. Each entry in a feed could then represent an individual
incident, or indicator, or some other resource, as appropriate. incident, or indicator, or some other resource, as appropriate.
Additional feeds could be used to represent other meaningful and Additional feeds could be used to represent other meaningful and
useful collections of cyber security resources. A feed may be useful collections of cyber security resources. A feed may be
categorized, and any feed may contain information from zero or more categorized, and any feed may contain information from zero or more
categories. The naming scheme and the semantic meaning of the terms categories. The naming scheme and the semantic meaning of the terms
used to identify an Atom category are application-defined. used to identify an Atom category are application-defined.
4.1. Dynamic Service Discovery versus Static URL Template This document assumes that the reader has an understanding of both
Atom documents. Further discussion of Atom's application to this
In order to specify a protocol for cyber security information sharing domain a well of examples of its use are provided in the BCG
using the REST architectural style it is necessary to define the set document.
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.
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.
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.
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.
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.
Normative requirements are defined below, in Section 5.
4.2. Non-Normative Examples
4.2.1. Service Discovery
This section provides a non-normative example of a client doing
service discovery.
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:
Example of bootstrapping Service Document discovery:
<link rel="introspection" type="application/atomsvc+xml" title="Atom Publishing Protocol Service Document" href="/csirt/svcdoc.xml" />
A client may then format an HTTP GET request to retrieve the service
document:
GET /csirt/svcdoc.xml
Host: www.example.org
Accept: application/atomsvc+xml
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.
Example HTTP GET response:
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>
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.
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.
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>
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.
4.2.2. Feed Retrieval
This section provides a non-normative example of a client retrieving
an incident feed.
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.
Example HTTP GET request for a Feed:
GET /csirt/private/incidents
Host: www.example.org
Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing
the incidents feed:
Example HTTP GET response for a Feed:
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>
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.
4.2.3. Entry Retrieval
This section provides a non-normative example of a client retrieving
an incident as an Atom entry.
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.
Example HTTP GET request for an Entry:
GET /csirt/private/incidents/123456
Host: www.example.org
Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing
the incident:
Example HTTP GET response for an Entry:
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>
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.
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 Section 5, below.
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.).
4.2.4. Use of Link Relations
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.
Individual CSIRTs may always define their own link relation types in
order to support specific use cases, however support for a core set
of well-known link relation types is encouraged as this will maximize
interoperability.
In addition, it may be beneficial to define use case profiles that
correspond to specific groupings of supported link relationship
types. In this way, a CSIRT may unambiguously specify the classes of
use cases for which a client can expect to find support.
The following sections provide NON-NORMATIVE examples of link
relation usage. 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.
4.2.4.1. Use Case: Incident Sharing
This section provides a non-normative example of an incident sharing
use case.
In this use case, a member CSIRT shares incident information with
another member CSIRT in the same consortium. The client CSIRT
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.
Example HTTP GET response for an incident entry:
<?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>
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.
4.2.4.2. Use Case: Collaborative Investigation
This section provides a non-normative example of a collaborative
investigation use case.
In this use case, two member CSIRTs that belong to a closed sharing
consortium are collaborating on an incident investigation. The
initiating CSIRT performs an HTTP GET to retrieve the service
document of the peer CSIRT, and determines the collection name to be
used for creating a new investigation request. The initiating CSIRT
then POSTs a new incident entry to the appropriate collection URL.
The target CSIRT acknowledges the request by responding with an HTTP
status code 201 Created.
Example HTTP GET response for the service document:
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:09:11 GMT
Content-Length: 934
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace xml:lang="en-US" xmlns:xml="http://www.w3.org/XML/1998/namespace">
<atom:title type="text">RID Use Case Requests</atom:title>
<collection href="http://www.example.org/csirt/RID/InvestigationRequests">
<atom:title type="text">Investigation Requests</atom:title>
<accept>application/atom+xml; type=entry</accept> <!-- 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>
As can be seen in the example response, the Atom <collection>
elements enable the client to determine the appropriate collection
URL to request an investigation or a trace.
The client CSIRT then POSTs a new entry to the appropriate feed
collection. Note that the <content> element of the new entry may
contain a RID message of type "InvestigationRequest" if desired,
however this would NOT be required. The entry content itself need
only be an IODEF document, with the choice of the target collection
resource URL indicating the callers intent. A CSIRT would be free to
use any URI template to accept investigationRequests.
POST /csirt/RID/InvestigationRequests HTTP/1.1
Host: www.example.org
Content-Type: application/atom+xml;type=entry
Content-Length: 852
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<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>
The receiving CSIRT acknowledges the request with HTTP return code
201 Created.
HTTP/1.1 201 Created
Date: Fri, 24 Aug 2012 19:17:11 GMT
Content-Length: 906
Content-Type: application/atom+xml;type=entry
Location: http://www.example.org/csirt/RID/InvestigationRequests/823
ETag: "8a9h9he4qphqh"
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<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>
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.
4.2.4.3. Use Case: Search (Query)
This section provides a non-normative example of a search use case.
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.
An HTTP response body may include a link relationship of type
"search." This link provides a reference to an OpenSearch
description document.
Example HTTP response that includes a "search" link:
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>
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:
Example HTTP response that includes a "search" link:
<?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}&amp;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>
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.
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.
4.2.4.4. Use Case: Cyber Data Repository
This section provides a non-normative example of a cyber security
data repository use case.
In this use case a client accesses a persistent repository of cyber
security data via a RESTful usage model. Retrieving a feed
collection is analogous to an SQL SELECT statement producing a result
set. Retrieving an individual Atom Entry is analogous to a SQL
SELECT statement based upon a primary key producing a unique record.
The cyber security data contained in the repository may include
different data types, including indicators, incidents, 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.
Example HTTP GET request to a persistent repository for any resources
representing Distributed Denial of Service (DDOS) attacks:
GET /csirt/repository/ddos
Host: www.example.org
Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing
the DDOS feed.
Example HTTP GET response for a DDOS feed:
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: nnnn
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns: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>
This feed document has two atom entries, one of which has been
elided. The completed entry illustrates an Atom <entry> element that
provides a summary of essential details about one particular DDOS
incident. Based upon this summary information and the provided
category information, a client may choose to do an HTTP GET operation
to retrieve the full details of the DDOS incident. This example
shows how a persistent repository may provide links to additional
resources, both local and remote.
Note that the provider of a persistent repostory is not obligated to
follow any particular URL template scheme. The repository available
at the hypothetical provider "www.example.com" uses a different URL
pattern than the hypothetical repository available at "www.cyber-
agency.gov". When a client de-references a link to resource that is
located in a remote repository the client may be challenged for
authentication credentials acceptable to that provider. If the two
repository providers choose to support a federated identity scheme or
some other form of single-sign-on technology, then the user
experience can be improved for interactive clients (e.g., a human
user at a browser). However, this is not required and is an
implementation choice that is out of scope for this specification.
5. Requirements for RESTful (Atom+xml) Binding 5. Normative Requirements TODO
This section provides the NORMATIVE requirements for using Atom This section provides the NORMATIVE requirements for using Atom
format and Atom Pub as a RESTful binding for cyber security format and Atom Pub as a RESTful binding for cyber security
information sharing. information sharing.
5.1. Transport Layer Security 5.1. Atom Requirements
Servers implementing this specification MUST support server- Implementations of this specification MUST implement all requirements
authenticated TLS. specified in Atom Publishing Protocol and the Atom Syndication
Format. (TODO: work on a more normative and perhaps constrained
requirement.)
Servers MAY support mutually authenticated TLS. 5.2. Transport Layer Security
5.2. Archiving and Paging Implementations MUST support server-authenticated TLS.
A feed may contain an arbitrary number of entries. In some cases, Implementations MAY support mutually authenticated TLS.
5.3. Archiving and Paging
A feed can contain an arbitrary number of entries. In some cases,
the complete response to a given query may consist of a logical the complete response to a given query may consist of a logical
result set that contains a large number of entries. As a practical result set that contains a large number of entries. As a practical
matter, the full result set may need to be divided into more matter, the full result set will likely need to be divided into more
managable portions. For example, a query may produce a full result manageable portions. For example, a query may produce a full result
set that may need to be grouped into logical pages, for purposes of set that may need to be grouped into logical pages, for purposes of
rendering on a user interface. rendering on a user interface.
An historical feed may need to be stable, and/or divided into some An historical feed may need to be stable, and/or divided into some
defined epochs. defined epochs. Implementations SHOULD support the mechanisms
described in Feed Paging and Archiving [RFC5005] to provide
Use cases that require capabilities for paging and archiving of feeds capabilities for paging and archiving of feeds.
SHOULD support the mechanisms described in Feed Paging and Archiving
[RFC5005].
5.3. Expectation and Impact Classes 5.4. Expectation and Impact Classes
It is frequently the case that a CSIRT organization will need to It is frequently the case that an organization will need to triage
triage their investigation and response activities based upon, e.g., their investigation and response activities based upon, e.g., the
the state of the current threat environment, or simply as a result of state of the current threat environment, or simply as a result of
having limited resources. having limited resources.
In order to enable CSIRTs to effectively prioritize their response In order to enable operators to effectively prioritize their response
activity, it is RECOMMENDED that feed implementors provide Atom activity, it is RECOMMENDED that feed implementers provide Atom
categories that correspond to the IODEF Expectation and Impact categories that correspond to the IODEF Expectation and Impact
classes. The availability of these feed categories will enable classes. The availability of these feed categories will enable
clients to more easily retrieve and prioritize cyber security clients to more easily retrieve and prioritize cyber security
information that has already been identified as having a specific information that has already been identified as having a specific
potential impact, or having a specific expectation. potential impact, or having a specific expectation.
Support for these catagories may also enable efficiencies for Support for these categories may also enable efficiencies for
organizations that already have established (or plan to establish) organizations that already have established (or plan to establish)
operational processes and workflows that are based on these IODEF operational processes and workflows that are based on these IODEF
classes. classes.
5.4. User Authentication 5.5. User Authentication
Servers MUST require user authentication. Implementations MUST support user authentication. User
authentication MAY be enabled for specific feeds.
Servers MAY support more than one client authentication method. Implementations MAY support more than one client authentication
method.
Servers participating in an information sharing consotium and Servers participating in an information sharing consortium and
supporting interactive user logins by members of the consortium supporting interactive user logins by members of the consortium
SHOULD support client authentication via a federated identity scheme SHOULD support client authentication via a federated identity scheme
as per SAML 2.0. as per SAML 2.0.
Servers MAY support client authenticated TLS. Implementations MAY support client authenticated TLS.
5.5. User Authorization 5.6. User Authorization
This document does not mandate the use of any specific user This document does not mandate the use of any specific user
authorization mechanisms. However, service implementers SHOULD authorization mechanisms. However, service implementers SHOULD
provide appropriate authorization checking for all resource accesses, provide appropriate authorization checking for all resource accesses,
including individual Atom Entries, Atom Feeds, and Atom Service including individual Atom Entries, Atom Feeds, and Atom Service
Documents. Documents.
Authorization for a resource MAY be adjudicated based on the value(s) Authorization for a resource MAY be adjudicated based on the value(s)
of the associated Atom <category> element(s). of the associated Atom <category> element(s).
When the content model for the Atom <content> element of an Atom When the content model for the Atom <content> element of an Atom
Entry contains an <IODEF-Document>, then authorization MUST be Entry contains an <IODEF-Document>, then authorization MUST be
adjudicated based upon the Atom <category> element(s), whose values adjudicated based upon the Atom <category> element(s), whose values
have been mapped as per Section 5.9. have been mapped as per Section 5.10.
Any use of the <category> element(s) as an input to an authorization Any use of the <category> element(s) as an input to an authorization
policy decision MUST include both the "scheme" and "term" attributes policy decision MUST include both the "scheme" and "term" attributes
contained therein. As described in Section 5.9 below, the namespace contained therein. As described in Section 5.10 below, the namespace
of the "term" attribute is scoped by the associated "scheme" of the "term" attribute is scoped by the associated "scheme"
attribute. attribute.
5.6. Content Model 5.7. Content Model
Member entry resources providing a representation of an incident Member entry resources providing a representation of an incident
resource (e.g., as specified in the link relation type) MUST use the resource (e.g., as specified in the link relation type) MUST use the
IODEF schema as the content model for the Atom Entry <content> IODEF schema as the content model for the Atom Entry <content>
element. element.
Member Entry resources providing a representation of an indicator Member Entry resources providing a representation of an indicator
resource (e.g., as specified in the link relation type) MUST use the resource (e.g., as specified in the link relation type) MUST use the
IODEF schema as the content model for the Atom Entry <content> IODEF schema as the content model for the Atom Entry <content>
element. element.
skipping to change at page 31, line 38 skipping to change at page 10, line 20
The resource representation MAY include an appropriate indicator The resource representation MAY include an appropriate indicator
schema type within the <AdditionalData> element of the IODEF Incident schema type within the <AdditionalData> element of the IODEF Incident
class. Supported indicator schema types SHALL be registered via an class. Supported indicator schema types SHALL be registered via an
IANA table (todo: IANA registration/review). IANA table (todo: IANA registration/review).
Member Entry resources providing a representation of a RID report Member Entry resources providing a representation of a RID report
resource (e.g., as specified in the link relation type) MUST use the 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. RID schema as the content model for the Atom Entry <content> element.
Member Entry resources providing representation of other types, Member Entry resources providing representation of other types,
SHOULD use the IODEF schema as the content model for the Atom Entry SHOULD use the schema appropriate for their data category as the
<content> element. content model for the Atom Entry <content> element. These data
categories SHALL be registered via an IANA table.
If the member entry content model is not IODEF, then the <content> The <content> element of the Atom entry MUST contain an appropriate
element of the Atom entry MUST contain an appropriate XML namespace XML namespace declaration.
declaration.
5.7. HTTP methods 5.8. HTTP methods
The following table defines the HTTP [RFC2616] uniform interface The following table defines the HTTP [RFC7235] uniform interface
methods supported by this specification: methods supported by this specification:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| HTTP | Description | | HTTP | Description |
| method | | | method | |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| GET | Returns a representation of an individual member entry | | GET | Returns a representation of an individual member entry |
| | resource, or a feed collection. | | | resource, or a feed collection. |
| PUT | Replaces the current representation of the specified | | PUT | Replaces the current representation of the specified |
| | member entry resource with the representation provided | | | member entry resource with the representation provided |
| | in the HTTP request body. | | | in the HTTP request body. |
| POST | Creates a new instance of a member entry resource. The | | POST | Creates a new instance of a member entry resource. The |
| | representation of the new resource is provided in the | | | representation of the new resource is provided in the |
| | HTTP request body. | | | HTTP request body. |
| DELETE | Removes the indicated member entry resource, or feed | | DELETE | Removes the indicated member entry resource, or feed |
| | collection. | | | collection. |
| HEAD | Returns metadata about the member entry resource, or | | HEAD | Returns metadata about the member entry resource, or |
| | feed collection, contained in HTTP response headers. | | | feed collection, contained in HTTP response headers. |
| PATCH | Support TBD. | | PATCH | Support TBD. |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
Table 1: Uniform Interface for Resource-Oriented Lightweight Table 1: Uniform Interface for Resource-Oriented Lightweight
Indicator Exchange Indicator Exchange
Clients MUST be capable of recognizing and prepared to process any Clients MUST be capable of recognizing and prepared to process any
standard HTTP status code, as defined in [RFC2616] standard HTTP status code, as defined in [RFC7235]
5.8. Service Discovery 5.9. Service Discovery
This specification requires that a CSIRT MUST publish an Atom Service This specification requires that a implementation MUST publish an
Document that describes the set of cyber security information sharing Atom Service Document that describes the set of cyber security
feeds that are provided. information sharing feeds that are provided.
The service document SHOULD be discoverable via the CSIRT The service document SHOULD be discoverable via the organization's
organization's Web home page or another well-known public resource. Web home page or another well-known public resource.
5.8.1. Workspaces 5.9.1. Workspaces
The service document MAY include multiple workspaces. Any CSIRT The service document MAY include multiple workspaces. Any producer
providing both public feeds and private consortium feeds MUST place providing both public feeds and private consortium feeds MUST place
these different classes of feeds into different workspaces, and these different classes of feeds into different workspaces, and
provide appropriate descriptions and naming conventions to indicate provide appropriate descriptions and naming conventions to indicate
the intended audience of each workspace. the intended audience of each workspace.
5.8.2. Collections 5.9.2. Collections
A CSIRT MAY provide any number of collections within a given An implementation MAY provide any number of collections within a
Workspace. It is RECOMMENDED that each collection appear in only a given Workspace. It is RECOMMENDED that each collection appear in
single Workspace. It is RECOMMENDED that at least one collection be only a single Workspace. It is RECOMMENDED that at least one
provided that accepts new incident reports from users. At least one collection be provided that accepts new incident reports from users.
collection MUST provide a feed of incident information for which the At least one collection MUST provide a feed of incident information
content model for the entries uses the IODEF schema. The title of for which the content model for the entries uses the IODEF schema.
this collection SHOULD be "Incidents". The title of this collection SHOULD be "Incidents".
5.8.3. Service Document Security 5.9.3. Service Document Security
Access to the service document MUST be protected via server- Access to the service document MUST be protected via server-
authenticated TLS and a server-side certificate. authenticated TLS and a server-side certificate.
When deploying a service document for use by a closed consortium, the When deploying a service document for use by a closed consortium, the
service document MAY also be digitally signed and/or encrypted, using service document MAY also be digitally signed and/or encrypted, using
XML DigSig and/or XML Encryption, respectively. XML DigSig and/or XML Encryption, respectively.
5.9. Category Mapping 5.10. Category Mapping
This section defines normative requirements for mapping IODEF This section defines normative requirements for mapping IODEF
metadata to corresponding Atom category elements. (todo: decide metadata to corresponding Atom category elements. (todo: decide
between IANA registration of scheme, or use a full URI). between IANA registration of scheme, or use a full URI).
5.9.1. Collection Category 5.10.1. Collection Category
An Atom collection MAY hold entries from one or more categories. The An Atom collection MAY hold entries from one or more categories. The
collection category set MUST contain at least the union of all the collection category set MUST contain at least the union of all the
member entry categories. A collection MAY have additional category member entry categories. A collection MAY have additional category
metadata that are unique to the collection, and not applicable to any metadata that are unique to the collection, and not applicable to any
individual member entry. A collection containing IODEF incident individual member entry. A collection containing IODEF incident
content MUST contain at least two <category> elements. One category content MUST contain at least two <category> elements. One category
MUST be specified with the value of the "scheme" attribute as MUST be specified with the value of the "scheme" attribute as
"restriction". One category MUST be specified with the value of the "restriction". One category MUST be specified with the value of the
"scheme" attribute as "purpose". The value of the "fixed" attribute "scheme" attribute as "purpose". The value of the "fixed" attribute
for both of these category elements MUST be "yes". When the category for both of these category elements MUST be "yes". When the category
scheme="restriction", the allowable values for the "term" attribute scheme="restriction", the allowable values for the "term" attribute
are constrained as per section 3.2 of IODEF, e.g. public, need-to- are constrained as per section 3.2 of IODEF, e.g. public, need-to-
know, private, default. When the category scheme="purpose", the know, private, default. When the category scheme="purpose", the
allowable values for the "term" attribute are constrained as per allowable values for the "term" attribute are constrained as per
section 3.2 of IODEF, e.g. traceback, mitigation, reporting, other. section 3.2 of IODEF, e.g. traceback, mitigation, reporting, other.
5.9.2. Entry Category 5.10.2. Entry Category
An Atom entry containing IODEF content MUST contain at least two An Atom entry containing IODEF content MUST contain at least two
<category> elements. One category MUST be specified with the value <category> elements. One category MUST be specified with the value
of the "scheme" attribute as "restriction". One category MUST be of the "scheme" attribute as "restriction". One category MUST be
specified with the value of the "scheme" attribute as "purpose". specified with the value of the "scheme" attribute as "purpose".
When the category scheme="restriction", the value of the "term" When the category scheme="restriction", the value of the "term"
attribute must be exactly one of ( public, need-to-know, private, attribute must be exactly one of ( public, need-to-know, private,
default). When the category scheme="purpose", the value of the default). When the category scheme="purpose", the value of the
"term" attribute must be exactly one of (traceback, mitigation, "term" attribute must be exactly one of (traceback, mitigation,
reporting, other). When the purpose is "other".... reporting, other). When the purpose is "other"....
Any member entry MAY have any number of additional categories. Any member entry MAY have any number of additional categories.
5.10. Entry ID 5.11. Entry ID
The ID element for an Atom entry SHOULD be established via the The ID element for an Atom entry SHOULD be established via the
concatenation of the value of the name attribute from the IODEF concatenation of the value of the name attribute from the IODEF
<IncidentID> element and the corresponding value of the <IncidentID> <IncidentID> element and the corresponding value of the <IncidentID>
element. This requirement ensures a simple and direct one-to-one element. This requirement ensures a simple and direct one-to-one
relationship between an IODEF incident ID and a corresponding Feed relationship between an IODEF incident ID and a corresponding Feed
entry ID and avoids the need for any system to maintain a persistent entry ID and avoids the need for any system to maintain a persistent
store of these identity mappings. store of these identity mappings.
(todo: Note that this implies a constraint on the IODEF document that (todo: Note that this implies a constraint on the IODEF document that
is more restrictive than the current IODEF schema. IODEF section 3.3 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 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 that name must be an IRI. Possible request to update IODEF to
constrain, or to support a new element or attribute). constrain, or to support a new element or attribute).
5.11. Entry Content 5.12. Entry Content
The <content> element of an Atom <entry> SHOULD include an IODEF The <content> element of an Atom <entry> SHOULD include an IODEF
document. The <entry> element SHOULD include an appropriate XML document. The <entry> element SHOULD include an appropriate XML
namespace declaration for the IODEF schema. If the content model of namespace declaration for the IODEF schema. If the content model of
the <entry> element does not follow the IODEF schema, then the the <entry> element does not follow the IODEF schema, then the
<entry> element MUST include an appropriate XML namespace <entry> element MUST include an appropriate XML namespace
declaration. declaration.
A client MAY ignore content that is not using the IODEF schema. A client MAY ignore content that is not using the IODEF schema.
5.12. Link Relations 5.13. Link Relations
In addition to the standard Link Relations defined by the Atom In addition to the standard Link Relations defined by the Atom
specification, this specification defines the following additional specification, this specification defines the following additional
Link Relation terms, which are introduced specifically in support of Link Relation terms, which are introduced specifically in support of
the Resource-Oriented Lightweight Indicator Exchange protocol. the Resource-Oriented Lightweight Information Exchange protocol.
+-----------------------+-----------------------------+-------------+ +-----------------------+-----------------------------+-------------+
| Name | Description | Conformance | | Name | Description | Conformance |
+-----------------------+-----------------------------+-------------+ +-----------------------+-----------------------------+-------------+
| service | Provides a link to an atom | MUST | | service | Provides a link to an atom | MUST |
| | service document associated | | | | service document associated | |
| | with the collection feed. | | | | with the collection feed. | |
| search | Provides a link to an | MUST | | search | Provides a link to an | MUST |
| | associated Open Search | | | | associated Open Search | |
| | document that describes a | | | | document that describes a | |
| | URL template for search | | | | URL template for search | |
| | queries. | | | | queries. | |
| history | Provides a link to a | MUST | | history | Provides a link to a | MUST |
| | collection of zero or more | | | | collection of zero or more | |
| | historical entries that are | | | | historical entries that are | |
| | associated with the | | | | associated with the | |
| | resource. | | | | resource. | |
| incidents | Provides a link to a | MUST | | incidents | Provides a link to a | MUST |
| | collection of zero or more | | | | collection of zero or more | |
| | instances of actual cyber | | | | instances of incident | |
| | security event(s) that are | | | | representations associated | |
| | associated with the | | | | with the resource. | |
| | resource. | |
| indicators | Provides a link to a | MUST | | indicators | Provides a link to a | MUST |
| | collection of zero or more | | | | collection of zero or more | |
| | instances of cyber security | | | | instances of cyber security | |
| | indicators that are | | | | indicators that are | |
| | associated with the | | | | associated with the | |
| | resource. | | | | resource. | |
| information | Provides a link to a | MUST |
| | collection of zero or more | |
| | instances of cyber security | |
| | information that is | |
| | associated with the | |
| | resource. | |
| evidence | Provides a link to a | SHOULD | | evidence | Provides a link to a | SHOULD |
| | collection of zero or more | | | | collection of zero or more | |
| | resources that provides | | | | resources that provides | |
| | some proof of attribution | | | | some proof of attribution | |
| | for an incident. The | | | | for an incident. The | |
| | evidence may or may not | | | | evidence may or may not | |
| | have any identified chain | | | | have any identified chain | |
| | of custody. | | | | of custody. | |
| campaign | Provides a link to a | SHOULD | | campaign | Provides a link to a | SHOULD |
| | collection of zero or more | | | | collection of zero or more | |
skipping to change at page 36, line 15 skipping to change at page 15, line 4
| | RID reports. | | | | RID reports. | |
| traceRequests | Provides a link to a | SHOULD | | traceRequests | Provides a link to a | SHOULD |
| | collection of zero or more | | | | collection of zero or more | |
| | resources that represent | | | | resources that represent | |
| | RID traceRequests. | | | | RID traceRequests. | |
| investigationRequests | Provides a link to a | SHOULD | | investigationRequests | Provides a link to a | SHOULD |
| | collection of zero or more | | | | collection of zero or more | |
| | resources that represent | | | | resources that represent | |
| | RID investigationRequests. | | | | RID investigationRequests. | |
+-----------------------+-----------------------------+-------------+ +-----------------------+-----------------------------+-------------+
Table 2: Link Relations for Resource-Oriented Lightweight Indicator Table 2: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
Unless specifically registered with IANA these short names MUST be Unless specifically registered with IANA these short names MUST be
fully qualified via concatenation with a base-uri. An appropriate fully qualified via concatenation with a base-uri. An appropriate
base-uri could be established via agreement amongst the members of an base-uri could be established via agreement amongst the members of an
information sharing consortium. For example, the rel="indicators" information sharing consortium. For example, the rel="indicators"
relationship would become relationship would become
rel="http://www.example.org/csirt/incidents/relationships/ rel="http://www.example.org/rolie/incidents/relationships/
indicators." indicators."
5.12.1. Additional Link Relation Requirements 5.13.1. Additional Link Relation Requirements
An IODEF document that is carried in an Atom Entry SHOULD NOT contain An IODEF document that is carried in an Atom Entry SHOULD NOT contain
a <relatedActivity> element. Instead, the related activity SHOULD be a <relatedActivity> element. Instead, the related activity SHOULD be
available via a link rel=related. available via a link rel=related.
An IODEF document that is carried in an Atom Entry SHOULD NOT contain An IODEF document that is carried in an Atom Entry SHOULD NOT contain
a <history> element. Instead, the related history SHOULD be a <history> element. Instead, the related history SHOULD be
available via a link rel="history" (todo: or a fully qualified link available via a link rel="history" (todo: or a fully qualified link
rek name). The associated href MAY leverage OpenSearch to specify rek name). The associated href MAY leverage OpenSearch to specify
the required query. the required query.
An Atom Entry MAY include additional link relationships not specified An Atom Entry MAY include additional link relationships not specified
here. If a client encounters a link relationship of an unkown type here. If a client encounters a link relationship of an unknown type
the client MUST ignore the offending link and continue processing the the client MUST ignore the offending link and continue processing the
remaining resource representation as if the offending link element remaining resource representation as if the offending link element
did not appear. did not appear.
5.13. Member Entry Forward Security 5.14. Member Entry Forward Security
As described in Authorization Policy Enforcement As described in Authorization Policy Enforcement a RESTful model for
(Authorization Policy Enforcement) a RESTful model for cyber security cyber security information sharing requires that all of the required
information sharing requires that all of the required security security enforcement for feeds and entries MUST be enforced at the
enforcement for feeds and entries MUST be enforced at the source source system, at the point the representation of the given
system, at the point the representation of the given resource(s) is resource(s) is created. A provider SHALL NOT return any feed content
created. A CSIRT provider SHALL NOT return any feed content or or member entry content for which the client identity has not been
member entry content for which the client identity has not been
specifically authenticated, authorized, and audited. specifically authenticated, authorized, and audited.
Sharing communities that have a requirement for forward message Sharing communities that have a requirement for forward message
security (such that client systems are required to participate in security (such that client systems are required to participate in
providing message level security and/or distributed authorization providing message level security and/or distributed authorization
policy enforcement), MUST use the RID schema as the content model for policy enforcement), MUST use the RID schema as the content model for
the member entry <content> element. the member entry <content> element.
5.14. Date Mapping 5.15. Date Mapping
The Atom feed <updated> element MUST be populated with the current The Atom feed <updated> element MUST be populated with the current
time at the instant the feed representation was generated. The Atom time at the instant the feed representation was generated. The Atom
entry <published> element MUST be populated with the same time value entry <published> element MUST be populated with the same time value
as the <reportTime> element from the IODEF document. as the <reportTime> element from the IODEF document.
5.15. Search 5.16. Search
Implementers MUST support OpenSearch 1.1 [opensearch] as the Implementers MUST support OpenSearch 1.1 [opensearch] as the
mechanism for describing how clients may form search requests. mechanism for describing how clients may form search requests.
Implementers MUST provide a link with a relationship type of Implementers MUST provide a link with a relationship type of
"search". This link SHALL return an Open Search Description Document "search". This link SHALL return an Open Search Description Document
as defined in OpenSearch 1.1. as defined in OpenSearch 1.1.
Implementers MUST support an OpenSearch 1.1 compliant search URL Implementers MUST support an OpenSearch 1.1 compliant search URL
template that enables a search query via Atom Category, including the template that enables a search query via Atom Category, including the
skipping to change at page 38, line 8 skipping to change at page 16, line 46
Collections that support use of the RID schema as a content model in 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 the Atom member entry <content> element (e.g. in a report resource
representation reachable via the "report" link relationship) MUST representation reachable via the "report" link relationship) MUST
support search operations that include the RID MessageType as a support search operations that include the RID MessageType as a
search parameter, in addition to the aforementioned IODEF schema search parameter, in addition to the aforementioned IODEF schema
elements, as contained within the <ReportSchema> element. elements, as contained within the <ReportSchema> element.
Implementers MUST fully qualify all OpenSearch URL template parameter Implementers MUST fully qualify all OpenSearch URL template parameter
names using the defined IODEF or RID XML namespaces, as appropriate. names using the defined IODEF or RID XML namespaces, as appropriate.
5.16. / (forward slash) Resource URL 5.17. / (forward slash) Resource URL
The "/" resource MAY be provided for compatibility with existing The "/" resource MAY be provided for compatibility with existing
deployments that are using Transport of Real-time Inter-network deployments that are using Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546]. Consistent with Defense (RID) Messages over HTTP/TLS [RFC6546]. Consistent with
RFC6546 errata, a client requesting a GET on "/" MUST receive an HTTP RFC6546 errata, a client requesting a GET on "/" MUST receive an HTTP
status code 405 Method Not Allowed. An implementation MAY provide status code 405 Method Not Allowed. An implementation MAY provide
full support for RFC6546 such that a POST to "/" containing a full support for RFC6546 such that a POST to "/" containing a
recognized RID message type just works. Alternatively, a client recognized RID message type just works. Alternatively, a client
requesting a POST to "/" MAY receive an HTTP status code 307 requesting a POST to "/" MAY receive an HTTP status code 307
Temporary Redirect. In this case, the location header in the HTTP Temporary Redirect. In this case, the location header in the HTTP
response will provide the URL of the appropriate RID endpoint, and response will provide the URL of the appropriate RID endpoint, and
the client may repeat the POST method at the indicated location. the client may repeat the POST method at the indicated location.
This resource could also leverage the new draft by reschke that This resource could also leverage the new draft by reschke that
proposes HTTP status code 308 (cf: draft-reschke-http-status- proposes HTTP status code 308 (cf: draft-reschke-http-status-
308-07.txt). 308-07.txt).
6. Security Considerations 6. Security Considerations TODO
This document defines a resource-oriented approach to lightweight This document defines a resource-oriented approach to lightweight
indicator exchange using HTTP, TLS, Atom Syndicate Format, and Atom information exchange using HTTP, TLS, Atom Syndicate Format, and Atom
Publishing Protocol. As such, implementers must understand the Publishing Protocol. As such, implementers must understand the
security considerations described in those specifications. security considerations described in those specifications.
In addition, there are a number of additional security considerations In addition, there are a number of additional security considerations
that are unique to this specification. that are unique to this specification.
As described above in the section Authentication of Users The approach described herein is based upon all policy enforcements
(Section 3.2), the approach described herein is based upon all policy being implemented at the point when a resource representation is
enforcements being implemented at the point when a resource created. As such, producers sharing cyber security information using
representation is created. As such, CSIRTS sharing cyber security this specification must take care to authenticate their HTTP clients
information using this specification must take care to authenticate using a suitably strong user authentication mechanism. Sharing
their HTTP clients using a suitably strong user authentication communities that are exchanging information on well-known indicators
mechanism. Sharing communities that are exchanging information on and incidents for purposes of public education may choose to rely
well-known indicators and incidents for purposes of public education upon, e.g. HTTP Authentication, or similar. However, sharing
may choose to rely upon, e.g. HTTP Authentication, or similar. communities that are engaged in sensitive collaborative analysis and/
However, sharing communities that are engaged in sensitive or operational response for indicators and incidents targeting high
collaborative analysis and/or operational response for indicators and value information systems should adopt a suitably stronger user
incidents targeting high value information systems should adopt a authentication solution, such as TLS client certificates, or a risk-
suitably stronger user authentication solution, such as TLS client based or multi-factor approach. In general, trust in the sharing
certificates, or a risk-based or multi-factor approach. In general, consortium will depend upon the members maintaining adequate user
trust in the sharing consortium will depend upon the members authentication mechanisms.
maintaining adequate user authentication mechanisms.
Collaborating consortiums may benefit from the adoption of a Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon SAML-core federated identity solution, such as those based upon SAML-core
[SAML-core] and SAML-bind [SAML-bind] and SAML-prof [SAML-prof] for [SAML-core] and SAML-bind [SAML-bind] and SAML-prof [SAML-prof] for
Web-based authentication and cross-organizational single sign-on. Web-based authentication and cross-organizational single sign-on.
Dependency on a trusted third party identity provider implies that Dependency on a trusted third party identity provider implies that
appropriate care must be exercised to sufficiently secure the appropriate care must be exercised to sufficiently secure the
Identity provider. Any attacks on the federated identity system Identity provider. Any attacks on the federated identity system
would present a risk to the CISRT, as a relying party. Potential would present a risk to the CISRT, as a relying party. Potential
mitigations include deployment of a federation-aware identity mitigations include deployment of a federation-aware identity
provider that is under the control of the information sharing provider that is under the control of the information sharing
consortium, with suitably stringent technical and management consortium, with suitably stringent technical and management
controls. controls.
As discussed above in the section Authorization Policy Enforcement Authorization of resource representations is the responsibility of
(Section 3.3), authorization of resource representations is the the source system, i.e. based on the authenticated user identity
responsibility of the source system, i.e. based on the authenticated associated with an HTTP(S) request. The required authorization
user identity associated with an HTTP(S) request. The required policies that are to be enforced must therefore be managed by the
authorization policies that are to be enforced must therefore be security administrators of the source system. Various authorization
managed by the security administrators of the source system. Various architectures would be suitable for this purpose, such as RBAC [1]
authorization architectures would be suitable for this purpose, such and/or ABAC, as embodied in XACML [XACML]. In particular,
as RBAC [1] and/or ABAC, as embodied in XACML [XACML]. In implementers adopting XACML may benefit from the capability to
particular, implementers adopting XACML may benefit from the represent their authorization policies in a standardized,
capability to represent their authorization policies in a interoperable format.
standardized, interoperable format.
Additional security requirements such as enforcing message-level Additional security requirements such as enforcing message-level
security at the destination system could supplement the security security at the destination system could supplement the security
enforcements performed at the source system, however these enforcements performed at the source system, however these
destination-provided policy enforcements are out of scope for this destination-provided policy enforcements are out of scope for this
specification. Implementers requiring this capability should specification. Implementers requiring this capability should
consider leveraging, e.g. the <RIDPolicy> element in the RID schema. consider leveraging, e.g. the <RIDPolicy> element in the RID schema.
Refer to RFC6545 section 9 for more information. Refer to RFC6545 section 9 for more information.
When security policies relevant to the source system are to be When security policies relevant to the source system are to be
skipping to change at page 40, line 17 skipping to change at page 18, line 52
constitutes an undetected separation of duties (SOD) violation. It constitutes an undetected separation of duties (SOD) violation. It
is important to note that this risk is not unique to this is important to note that this risk is not unique to this
specification, and a similar potential for abuse exists with any specification, and a similar potential for abuse exists with any
other cyber security information sharing protocol. However, the wide other cyber security information sharing protocol. However, the wide
availability of tools for HTTP clients and Atom feed handling implies availability of tools for HTTP clients and Atom feed handling implies
that the resources and technical skills required for a successful that the resources and technical skills required for a successful
exploit may be less than it was previously. This risk can be best exploit may be less than it was previously. This risk can be best
mitigated through appropriate vetting of the client at account mitigated through appropriate vetting of the client at account
provisioning time. In addition, any increase in the risk of this provisioning time. In addition, any increase in the risk of this
type of abuse should be offset by the corresponding increase in type of abuse should be offset by the corresponding increase in
effectiveness that that this specification affords to the defenders. effectiveness that this specification affords to the defenders.
While it is a goal of this specification to enable more agile cyber While it is a goal of this specification to enable more agile cyber
security information sharing across a broader and varying security information sharing across a broader and varying
constituency, there is nothing in this specification that necessarily constituency, there is nothing in this specification that necessarily
requires this type of deployment. A cyber security information requires this type of deployment. A cyber security information
sharing consortium may chose to adopt this specification while sharing consortium may chose to adopt this specification while
continuing to operate as a gated community with strictly limited continuing to operate as a gated community with strictly limited
membership. membership.
7. IANA Considerations 7. IANA Considerations TODO
This document does not require any actions from IANA. TODO.
8. Acknowledgements 8. Acknowledgements
The author gratefully acknowledges the valuable contributions of Tom The author gratefully acknowledges the valuable contributions of Tom
Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts, and individuals provided detailed review comments on earlier drafts, and
many suggestions that have helped to improve this document . many suggestions that have helped to improve this document .
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Protocol (HTTP/1.1): Authentication", RFC 7235,
Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC7235, June 2014,
DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc7235>.
<http://www.rfc-editor.org/info/rfc2616>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
DOI 10.17487/RFC5005, September 2007, DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>. <http://www.rfc-editor.org/info/rfc5005>.
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
skipping to change at page 42, line 7 skipping to change at page 20, line 41
[SAML-bind] [SAML-bind]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Mahler, "Bindings for the OASIS Security Assertion Markup Mahler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard , March 2005, Language (SAML) V2.0", OASIS Standard , March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/ <http://docs.oasis-open.org/security/saml/v2.0/
saml-bindings-2.0-os.pdf>. saml-bindings-2.0-os.pdf>.
9.2. Informative References 9.2. Informative References
[XMLencrypt]
Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
Syntax and Processing", W3C Recommendation , December
2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Simon, "XML-Signature Syntax and Processing", W3C
Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-core/>.
[XACML] Rissanen, E., "eXtensible Access Control Markup Language [XACML] Rissanen, E., "eXtensible Access Control Markup Language
(XACML) Version 3.0", August 2010, <http://docs.oasis- (XACML) Version 3.0", August 2010, <http://docs.oasis-
open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>. open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>. top.htm>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
DOI 10.17487/RFC2396, August 1998,
<http://www.rfc-editor.org/info/rfc2396>.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
DOI 10.17487/RFC2822, April 2001,
<http://www.rfc-editor.org/info/rfc2822>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012, DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>. <http://www.rfc-editor.org/info/rfc6546>.
9.3. URIs 9.3. URIs
[1] http://csrc.nist.gov/groups/SNS/rbac/ [1] http://csrc.nist.gov/groups/SNS/rbac/
Appendix A. Change Tracking Appendix A. Change Tracking
Changes since -02 version, August 15, 2013 to December 2, 2015: Changes since draft-field-mile-rolie-01 version, December, 2015 to
May 27, 2016:
o Added section specifying the use of RFC5005 for Archive and Paging
of feeds. See: Section 5.2
o Added section describing use of atom categories that correspond to
IODEF expectation class and impact classes. See: Section 5.3
o Dropped references to adoption of a MILE-specific HTTP media type
parameter.
o Updated IANA Considerations section to clarify that no IANA
actions are required.
Appendix B. Resource Authorization Model
As described in Section 3.3.2 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.
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.
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.
The XACML 3.0 standard is based upon the notion that authorization o Spun section 4 and some related contextual information into its
policies are defined in terms of predicate logic expressions written own document see TODO:Add reference
against the attributes associated with one or more of the following
four entities:
o SUBJECT o Recast document into a more general use perspective. The
implication of CSIRTs as the defacto end-user has been removed
where ever possible. All of the original CSIRT based use cases
remain completely supported by this document, it has been opened
up to supported many other use cases.
o ACTION o Changed the content model to broaden support of representation
o RESOURCE o Edited and rewrote much of sections 1,2 and 3 in order to
accomplish a broader scope and greater readability
o ENVIRONMENT o Removed any requirements from the Background section and, if not
already stated, placed them in the requirements section
Thus, a suitable approach to a XACML 3.0 profile for ROLIE o Re-formatted the requirements section to make it clearer that it
authorization policies could begin by using the 3-tuple of [SUBJECT, contains the lions-share of the requirements of the specification
ACTION, RESOURCE] where:
o SUBJECT is the suitably authenticated identity of the requestor. Changes made in draft-ietf-mile-rolie-01 since draft-field-mile-
rolie-02 version, August 15, 2013 to December 2, 2015:
o ACTION is the associated HTTP method, GET, PUT, POST, DELETE, o Added section specifying the use of RFC5005 for Archive and Paging
HEAD, (PATCH). of feeds. See: Section 5.3
o RESOURCE is an XPath expression that uniquely identifies the o Added section describing use of atom categories that correspond to
instance or type of the ROLIE resource being requested. IODEF expectation class and impact classes. See: Section 5.4
Implementers who have a need may also choose to evaluate based upon o Dropped references to adoption of a MILE-specific HTTP media type
the additional ENVIRONMENT factors, such as current threat level, and parameter.
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.
Having these policies expressed in a standards-compliant and machine- o Updated IANA Considerations section to clarify that no IANA
readable format could improve the agility and effectiveness of a actions are required.
cyber security information sharing group or consortium, and enable
better cyber defenses.
Author's Address Authors' Addresses
John P. Field John P. Field
Pivotal Software, Inc. Pivotal Software, Inc.
625 Avenue of the Americas 625 Avenue of the Americas
New York, New York New York, New York
USA USA
Phone: (646)792-5770 Phone: (646)792-5770
Email: jfield@pivotal.io Email: jfield@pivotal.io
Stephen A. Banghart
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland
USA
Phone: (301)975-4288
Email: sab3@nist.gov
 End of changes. 98 change blocks. 
1229 lines changed or deleted 304 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/