1 THE MITRE CORPORATION Sample Usage of TAXII Version 1.0 (draft) Mark Davidson, Charles Schmidt 11/16/2012 The Trusted Automated exchange of Indicator Information (TAXII ) specifies mechanisms for exchanging structured cyber threat information between parties over the network. This document walks through detailed examples of how TAXII might be used by members of a sharing community.
2 Trademark Information TAXII and STIX are trademarks of The MITRE Corporation. This technical data was produced for the U. S. Government under Contract No. HSHQDC-11-J-00221, and is subject to the Rights in Technical Data-Noncommercial Items clause at DFARS (NOV 1995) 2012 The MITRE Corporation. All Rights Reserved. Feedback Community input is necessary for the success of TAXII. Feedback on this or any of the other TAXII Specifications is welcome and can be sent to Comments, questions, suggestions, and concerns are all appreciated. 1
3 Table of Contents Trademark Information... 1 Feedback Introduction TAXII Specifications STIX Terms and Definition TAXII Concepts TAXII Roles TAXII Network Components An Example of TAXII Support for Source/Subscriber Sharing The Participants Initial Preparation Architectures Data Handling - TAXII Data Feeds A Sample Source-Subscriber Interaction Step 1: Discovery Exchange Step 2: Feed Information Exchange Step 3: Acquire Authorization (Outside TAXII) Step 4: Subscription Management Exchange Step 5a: Data Push Exchange Step 5b: Feed Poll Exchange An Example of TAXII Support for Peer-to-Peer Sharing The Participants Initial Preparation A Sample Peer-to-Peer Interaction Step 1: Discovery Exchange Step 2: Data Push Exchanges Conclusion Bibliography
4 1 Introduction Trusted Automated exchange of Indicator Information (TAXII ) is a set of technical specifications and supporting documentation to enable sharing of actionable cyber threat information across organization and product/service boundaries. TAXII requirements are provided through multiple related specifications (see Section 1.1). This document provides a detailed descriptions of how sharing communities could use TAXII for their interactions. The purpose of this document is to illustrate the use of TAXII 1.0 in common usage scenarios using concrete examples. As such, this document does not contain normative requirements for the implementation of TAXII. Readers of this document should read it in conjunction with the TAXII Services Specification , the TAXII HTTP Binding Specification , and the TAXII Message Binding Specification for XML  as this document makes references to all three documents. Readers are advised to read these specification first, and then use this document to clarify expected behavior within each of the TAXII specifications. 1.1 TAXII Specifications TAXII is defined by multiple, interrelated specifications. This section describes the specifications that define TAXII. Services Specification - The TAXII Services Specification provides requirements that govern TAXII services and exchanges. It does not provide details on data formatting or how TAXII messages are transported over a network - such details and requirements can be found in the Protocol Binding Specifications and Message Binding Specifications. Protocol Binding Specification - Protocol Binding Specifications define the requirements for transporting TAXII messages over the network. There may be multiple Protocol Binding Specifications created for TAXII. Each Protocol Binding Specification defines requirements for transporting TAXII messages using some network protocol (e.g., HTTP). They provide requirements about how the TAXII Services are supported by these network protocols. Message Binding Specification - Message Binding Specifications define the requirements for representing TAXII messages in a particular format. There may be multiple Message Binding Specifications created for TAXII. Each Messaging Binding Specification defines a binding for TAXII messages (e.g., XML). They provide detailed guidance about how the information in the TAXII messages, as defined in the Services Specification, is actually expressed. Figure 1 shows how these specifications relate to each other. 3
5 TAXII Protocol Binding Specifications TAXII Services Specification Defines TAXII Services Defines TAXII Message Types Defines TAXII Message Exchanges Define requirements for network transport of TAXII messages TAXII Message Binding Specifications Define TAXII Message format bindings Figure 1 - TAXII Specification Hierarchy Separation of the Services Specification, Message Binding Specifications, and Protocol Binding Specifications exists to support flexibility as TAXII evolves. Threat information sharing communities often have specific constraints on the types of protocols they are able to support. Rather than binding TAXII to a specific protocol that excludes portions of the community, TAXII's core concepts (i.e., its services and exchanges) are defined separately from the protocol-level support for those concepts. When there is evidence of significant community interest in new protocol and message bindings, TAXII can define support for those bindings without changing its core components. Two groups that use the same network protocol and message bindings will be capable of automated exchanges of structured threat information. The sharing policies of the participants can limit these exchanges as needed, but the use of compatible TAXII services ensures that whatever sharing is permissible by policy can be effected by the TAXII mechanisms. Groups that use different protocol or message bindings for TAXII will not be able to communicate directly with each other, but because they are still using TAXII Messages and Services at the core of their communications means that it is possible to create gateways that will allow interaction to occur STIX TAXII is designed to support the sharing of structured cyber threat information. The structuring of this information is provided by the Structured Threat Information expression (STIX ). STIX is "a collaborative community-driven effort to define and develop a standardized language to represent structured cyber threat information."  This specification does not provide details about the underlying structures defined in the STIX specification, apart from noting that all cyber threat information transported by TAXII is expressed in 4
6 "STIX documents". Those interested in learning more about STIX are directed to the STIX web site at Terms and Definition This section defines terms that are assigned a specific meaning within all TAXII specifications: TAXII Concepts These terms are used throughout the document to define concepts central to definition of TAXII. TAXII Data Feed - A collection of structured cyber threat information expressible in one or more STIX documents that can be exchanged using TAXII. All TAXII Data Feeds MUST be assigned a name that uniquely identifies them on a given Producer. Individual pieces of cyber threat information within a TAXII Data Feed are labeled with a timestamp and may have other labels at the producer's discretion. TAXII Message - A discrete block of information that is passed from one entity to another. A TAXII Message represents either a request (e.g., Can I subscribe to this TAXII Data Feed? ) or a response (e.g., Yes. ). TAXII Message Exchange - A defined sequence of request and response TAXII Messages undertaken by two parties to accomplish a specific activity. TAXII Service - Functionality hosted by some entity that is accessed or invoked through the use of one or more TAXII Message Exchanges TAXII Roles TAXII Roles are used to denote participants in TAXII according to their high-level objectives in the use of TAXII Services. Producer - The role of an entity (e.g., a person, organization, agency, etc.) that is the source of structured cyber threat information. Consumer - The role of an entity that is the recipient of structured cyber threat information TAXII Network Components These terms are used to define the components of a TAXII Implementation using a typical client-server model. Note that these should be considered orthogonal to the TAXII Roles previously defined: An entity might both host a TAXII Server and use a TAXII Client in their role as a TAXII Consumer. The defined network components represent a network-centric view of TAXII participants while the defined roles represent an activity-centric view. TAXII Server - A TAXII implementation that provides one or more TAXII services. To support this functionality, it is assumed that a TAXII Server is persistently listening for new TAXII network traffic. TAXII Client - A TAXII implementation that initiates an exchange with a TAXII Server. A TAXII Client does not need a persistent connection on the network to operate but can open a connection when it wishes to interact with a TAXII server and disconnect from the network when this interaction has concluded. 5
7 2 An Example of TAXII Support for Source/Subscriber Sharing Previous work  has identified three models used by cyber threat information sharing communities to exchange threat information. These models are: Source/subscriber - The information provider pushes out regular information to all subscribers Peer-to-peer - Participants share and receive threat data directly Hub and spoke - One entity controls receipt and dissemination of cyber threat data that might be collected from multiple sources This section considers the first of these sharing models as it is the simplest and because this model can be a component of the other two. In a Source/Subscriber model information flow is unidirectional, from a single Source to each Subscriber. Figure 3 shows an example of a Source/Subscriber relationship. Subscriber Subscriber Source Subscriber Subscriber Figure 2 - The Source/Subscriber Sharing Model For this example, it is assumed all participants support the TAXII HTTP Protocol Binding 1.0  and TAXII XML Message Binding 1.0 . 2.1 The Participants In this model there is a Source that provides cyber threat information to some number of Subscribers who each enter into agreements with this Source to receive periodic content updates. The Subscribers are likely to be unknown to each other, so this represents a set of bi-lateral agreements that each Subscriber makes with the single Source. In this model, the Source is a TAXII Producer, while the Subscribers are TAXII Consumers. For the purposes of this example, this document assumes the following participants. Source - A vendor that collects, edits, and then sells threat intelligence information. This vendor might use TAXII to receive threat intelligence information, but for the sake of this example, only its interaction with customers is considered. Customers purchase contracts to receive threat intelligence information. 6
8 Contracts are tiered - those in the highest tiers receive the greatest amount of information, while those who purchase lower-tiered contracts get progressively less detail. The vendor also offers a free feed with very limited information as a public service/means to drive business. Subscriber - A customer of the aforementioned vendor. This customer represents a company that seeks to improve its security posture by making use of available cyber threat information. 2.2 Initial Preparation Prior to a TAXII exchange, both the Source and all would-be Subscribers must implement TAXII. Given that these participants have different activities in this exchange, their TAXII implementations will have different requirements. The two participants will also need to have an understanding of cyber threat information that is compatible with that information's expression using STIX Architectures Both participants must implement TAXII in order to participate in a TAXII exchange. The key distinction between these implementations is in the TAXII Services they support Source Architecture The Source might make use of several TAXII Services (as defined in the TAXII Service Specification). Note that it is possible for the Source to have a TAXII implementation that includes only some of the described TAXII Services. The applicable TAXII Services appear below along with their use and how the Source might provide the equivalent functionality without (or in addition to) using the identified TAXII Services TAXII Discovery Service Implementing a TAXII Discovery Service would allow a Subscriber to use TAXII to learn which services the Source offers and how to contact them. This might be especially useful if the Source implemented multiple TAXII Feed Management Services with different responsibilities and/or if the Source implemented one or more TAXII Poll Services. Interaction with the Discovery Service would inform the Subscriber as to which TAXII Services were offered, which protocol and message bindings those services supported, how to contact those services, and additional information, such as whether one needed a certain contract tier to access the service in question. If the Source does not provide a Discovery Service, this information needs to be provided through other means. For example, the Source could host a web page that contained a table with the relevant information. Alternatively, the Source might provide its customers with an application to interact with its services that was pre-configured with the relevant information. Other means of conveying the relevant information to the Subscriber through non-automated means are also possible TAXII Feed Management Service A TAXII Feed Management Service allows Subscribers to discover what TAXII Data Feeds are offered by the Source, including descriptive information about the nature of those feeds and what forms of delivery the Source is capable of providing for their content. In addition, through the Feed Management 7
9 Service a Subscriber could use TAXII Messages to create and manage subscriptions to those TAXII Data Feeds. If the Source does not provide a Feed Management Service, then advertisement of TAXII Data Feeds and management of subscriptions need to be handled through other means. A list of TAXII Data Feeds might be provided on a web page along with their delivery mechanisms. Subscription to a feed might be automatically integrated to the vendor's purchasing software, automatically creating a subscription when a customer purchases the appropriate contract. Other out-of-band mechanisms for creating subscriptions could also be implemented TAXII Poll Service A TAXII Poll Service allows Subscribers to pull TAXII Data Feed content instead of having the Source push this content to them. This can be useful to a Subscriber that, for policy reasons, prohibits the establishment of inbound connections. This also allows the Subscriber to collect information at times that are convenient to them rather than waiting for distributions by the Source. If the Source does not provide a Poll Service then all TAXII Data Feed content must be pushed to an Inbox Service hosted by the Subscriber. Alternatively, content could be disseminated through mechanisms not associated with TAXII TAXII Client for a Subscriber's Inbox Service If the Source pushes TAXII Data Feed content to the Subscriber, the Source will need a TAXII Client that sends this content to the Subscriber's TAXII Inbox Service. This push functionality does not require a TAXII Service, as defined in the TAXII Services Specification, but does require TAXII-compatible functionality on the part of the Source. Specifically, this functionality would need to format TAXII Data Feed content as a TAXII Message and then make a connection to the appropriate Subscriber Inbox Service to deliver this content. If the Source does not implement such a TAXII Client, the Source would need to host a Poll Service and all Subscribers would need pull content from the Source. Alternatively, content could be disseminated through mechanisms not associated with TAXII Subscriber Architecture Depending on how the Subscriber will be receiving content, they may or may not need to implement a TAXII Service. Specifically, if they are to receive content via push messaging, they will need to host a TAXII Inbox Service, but if they will only be pulling content from the Source the Subscriber does not require a TAXII Service although it would need a TAXII Client. The Subscriber will also need TAXII Clients capable of interacting with some or all of the other TAXII Services the Source provides TAXII Inbox Service If the Subscriber is to receive TAXII Messages via push messaging, then they must implement a TAXII Inbox Service. The Inbox Service can receive pushed TAXII Data Feed content for the Subscriber. The Inbox Service can also receive subscription alerts informing the Subscriber of current or impending changes to their existing subscriptions. 8
10 If the Subscriber does not implement a TAXII Inbox Service then they will need to contact a Poll Service on the Source in order to collect TAXII Data Feed content via pull messaging. Alternatively, they could receive content using mechanisms not associated with TAXII TAXII Client(s) The Subscriber would need a TAXII Client for any interactions they wished to have with any of the TAXII Services hosted by the Source, such as the Discovery Service, Feed Management Service, or Poll Service. The actual implementation of this functionality could take the form of a single application capable of interacting with all of these services, multiple applications each capable of interacting with a single TAXII Service, or something in between. The Subscriber's TAXII Client(s) would interact with these TAXII Services to learn the TAXII Services offered by the Source, create or manage subscriptions to TAXII Data Feeds, and/or collect TAXII Data Feed content via pull messaging, respectively. If the Source provides means to accomplish the activities associated with a service via mechanisms other than TAXII, a Subscriber could use those mechanisms instead of implementing the appropriate TAXII Client Data Handling - TAXII Data Feeds In addition to the described architectural components, both participants in a TAXII exchange must share a particular understanding of the structured cyber threat information that TAXII exchanges. As noted earlier, both participants must be able to express and understand structured cyber threat information using the STIX language. However, in addition to this, there must be an understanding of a TAXII Data Feed Source TAXII content dissemination is tightly bound to the concept of a TAXII Data Feed. When a subscription is created, it is to a specific, named TAXII Data Feed. As such, all content that the Source makes available via TAXII subscriptions must be assigned to one or more TAXII Data Feeds. The assignment of content to one or more TAXII Data Feeds is at the Source's discretion. For example, the Source might create a "Full" feed which included all content, and then several additional feeds which included (possibly overlapping) subsets of all content based on criteria such as contract level, membership in other sharing groups, or other special relationships. It is not necessary for TAXII Data Feeds to be the sole means by which content dissemination is controlled. For example, instead of having separate TAXII Data Feeds for each contract level, a vendor might define separate TAXII Data Feeds by the type of threat they discuss and dynamically elide information in those feeds just prior to sending them to a customer based on that customer's contract level. In fact, one could imagine a Source that had only a single TAXII Data Field that all of its customers used where that Source performed a series of rule-based edits to each piece of content prior to delivery so that each customer only saw content that was appropriate to their contract and access rights. That said, most Sources will probably find some benefit to defining some grouping of their content into TAXII Data Feeds as a means of managing access and allowing customers to receive material that they deem relevant to their operations. 9
11 In addition to mapping content to one or more TAXII Data Feed, each piece of content must be assigned a timestamp within each TAXII Data Feed to which it is mapped. It should be emphasized that this timestamp exists to provide a label used by exchanges associated with the TAXII Poll Service. It does not need to represent an actual chronological time - the Source could simply label the "first" piece of content in a TAXII Data Feed with the time T00:00:01 and increment this value with each subsequent piece of content in the TAXII Data Feed. This said, most Sources will probably find it easier to assign timestamps that are, in fact, chronologically meaningful. For example, a piece of content's timestamp could represent the time the content was created, the time the content was disseminated, the time of the event associated with the content, or some other meaning. Further note that the same piece of content could be labeled with a different timestamp in different TAXII Data Feeds. There is also no prohibition against multiple pieces of content within a single TAXII Data Feed sharing the same timestamp label. Since TAXII Data Feed timestamps are only utilized by exchanges with the TAXII Poll Service, if the Source does not provide Poll Service access to the TAXII Data Feed, it would not need to apply timestamp labels to that TAXII Data Feed's content Subscriber The Subscriber needs to be aware of the Feed Names associated with TAXII Data Feeds as these names are used when establishing subscriptions and polling for content. Likewise, if the Subscriber uses the Source's Poll Service, they will likely wish to track timestamps associated with prior Poll Requests in order to avoid pulling the same content multiple times. Note that a response to a Poll Request includes the bounding timestamps for the range of TAXII Data Feed content it is returning, but otherwise the Subscriber has no means of learning the timestamp a Source assigned to a particular piece of content. The timestamp is not intended to provide the Subscriber with a precise handle to specific pieces of content but simply a way to request non-overlapping ranges of data. Once a Subscriber has received a piece of content, there is no further need to associate that content with a specific Source-assigned TAXII Data Feed. 2.3 A Sample Source-Subscriber Interaction This section looks at the specific TAXII Message Exchanges that could be used to support interactions between a Source and a Subscriber. For this example, it is assumed that both participants have TAXII implementations that include all of the TAXII Services and TAXII Client functionality for their respective roles as described in the previous sections. It is also assumed that the Source has arranged their content into a set of TAXII Data Feeds and assigned timestamps to all this content. Figure 3 shows a sample sharing arrangement with a single Source and multiple Subscribers. The following sections look at each of the TAXII Message Exchanges that occur between the Source and a single Subscriber in the course of establishing a subscription (steps 1-4) and then having the Subscriber receive TAXII Data Feed content associated with that subscription (step 5). Note that step 3 represents activities outside the scope of the TAXII specifications. 10
12 Subscriber Subscriber Source Subscriber Subscriber Discovery Service Subscriber learns Source's Services TAXII Client 1 Feed Management Service Subscriber learns the TAXII Data Feeds managed by this Feed Management Service Subscriber subscribes to TAXII Data Feeds TAXII Client TAXII Client TAXII Client Poll Service Source pushes content to Subscriber and/or Subscriber polls Source for content Inbox Service TAXII Client 5a 5b Source Subscriber Figure 3 - Source/Subscriber Sharing Model For the sake of this example, it is assumed the Source and Subscriber have had no preceding interaction and, as such, have effectively no initial knowledge of each other. The one exception is that it is assumed the Subscriber is aware of the existence of the Source's Discovery Service and knows how to contact it. The information necessary to support this interaction might be posted on the Source's web site or in some other public location. The following sections show what the messages that constitute the identified exchanges might look like using the TAXII HTTP Protocol Binding and the TAXII XML Message Binding. A green background denotes the HTTP request or status lines along with the HTTP headers. A blue back denotes the HTTP message body, if present, expressed using the TAXII XML Message Binding. If a single line is too long to fit on one line of the diagram, a " " is used to indicate line wrapping for readability. 11
13 2.3.1 Step 1: Discovery Exchange As noted above, it is assumed that the Subscriber is aware of the Source's Discovery Service and possesses the information necessary to establish a connection with it. Such necessary information would include the TAXII Protocol Binding to use, the Discovery Service's network address using this binding, and the TAXII Message Binding used by the Discovery Service. The Subscriber constructs a Discovery Request Message (see Figure 4) and sends it to the Source's Discovery Service. The Source responds with a Discovery Response Message (see Figure 5). For these (and all following) examples, an arbitrary Message ID has been assigned to each message. Note that the In Response To field in the Discovery Response Message is identical to the Message ID field in the Discovery Request Message. Note also that the Source and Subscriber use different formats for their Message ID - this is permitted and should not cause conflicts. GET /?message_type=discovery_request&message_id= a847%2098be%20ffe8%2040ee%203722%20c893%20288b%20d375 HTTP/1.1 Host: taxiiserver.company.com Accept: application/xml Content-Type: application/xml User-Agent: TAXII client application X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTP_BINDING_1.0 Figure 4 - TAXII Discovery Request Message HTTP/ OK Content-Type: application/xml Content-Length: 2474 Date: Thu, 15 Nov :12:31 GMT X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTP_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_DiscoveryResponse xmlns=" message-id="984987de-feaa-95ff-894c-cbcc " in-response-to="a847 98be ffe8 40ee 3722 c b d375"> Continued 12
14 Continued <service-instance service-type="discovery" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <service-address> <message>corporate TAXII Discovery Service. This service provides information about all our products accessible through TAXII.</message> </service-instance> <service-instance service-type="feed-management" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <service-address> </service-address> <message>used to for free public data feeds</message> </service-instance> <service-instance service-type="poll" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <service-address> </service-address> <message>to support polling of public data feeds.</message> </service-instance> <service-instance service-type="feed-management" service-version="taxii_1.0"> <protocol-binding>taxii_https_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <service-address> </service-address> <message>used to for for-pay data feeds. To purchase a subscription, go to and follow the on-screen instructions.</message> </service-instance> <service-instance service-type="poll" service-version="taxii_1.0"> <protocol-binding>taxii_https_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <service-address> </service-address> <message>to support polling of for-pay data feeds.</message> </service-instance> </TAXII_DiscoveryResponse> Figure 5 - TAXII Discovery Response Message 13
15 For this example, it is assumed that the Source hosts a single Discovery Service and two instances each of a Feed Management Service and Poll Service, one pair of which is dedicated to providing for-pay services while the other pair provides free services. The Source might have additional TAXII Services that are only revealed to certain authenticated parties, but since the Subscriber has had no prior interaction with the Source, it cannot be usefully authenticated and those "secret" TAXII Services would not be revealed in this exchange. Note that some TAXII Services share an address (i.e., have the same URL) while others have different addresses. The mapping of Service implementations to network addresses is entirely at the discretion of the Source. From this exchange, the Subscriber learns of all the Source's TAXII Services (at least all the TAXII Services the Source is willing to tell the Subscriber about), the Protocol and Message Bindings those services support, and how to contact them. The source uses the Message fields in its Discovery Response to describe the different Services Step 2: Feed Information Exchange Having learned of the Source's offered TAXII Services, the Subscriber wishes to learn which Data Feeds are available. In this case, the Subscriber is interested in the for-pay feeds. As such, the Subscriber contacts the Source's for-pay TAXII Feed Management Service with a Feed Information Request Message (see Figure 6) to query it about the available TAXII Data Feeds. The Source responds with a Feed Information Response (see Figure 7). In this response, the Source identifies three TAXII Data Feeds. The Source uses the Description fields associated with these TAXII Data Feeds to describe what these feeds provide. It also notes how content associated with these TAXII Data Feeds can be disseminated. Note that the first two TAXII Data Feeds can be polled for information but the third cannot. GET /feeds/pay?message_type=discovery_request&message_id= a847%2098be%20ffe8%2040ee%203722%20c893%20288b%20d376 HTTP/1.1 Host: taxiiserver.company.com Accept: application/xml Content-Type: application/xml User-Agent: TAXII client application X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 Figure 6 - TAXII Feed Information Request Message 14
16 HTTP/ OK Content-Type: application/xml Content-Length: 1464 Date: Thu, 15 Nov :11:43 GMT X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTP_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_FeedInformationResponse xmlns=" message-id="984987de-feaa-95ff-894c-b845503eef3319ac" in-response-to="a847 98be ffe8 40ee 3722 c b de376"> <feed feed-name="platinum"> <description>our most comprehensive data feed containing up-tothe-minute threat information and professional analysis of impact and context. </description> <delivery-method>taxii_http_binding_1.0</delivery-method> <delivery-method>poll</delivery-method> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> </feed> <feed feed-name="gold"> <description>up-to-the-minute threat information covering global threats but with no additional analysis.</description> <delivery-method>taxii_http_binding_1.0</delivery-method> <delivery-method>poll</delivery-method> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> </feed> <feed feed-name="silver"> <description>a daily digest of the day's threats.</description> <delivery-method>taxii_http_binding_1.0</delivery-method> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> </feed> </TAXII_FeedInformationResponse> Figure 7 - TAXII Feed Information Response Message From this exchange, the Subscriber learns of the TAXII Data Feeds that can be managed through this particular Feed Management Service. Since, in our example, the Source hosts two Feed Management Services, the Subscriber might wish to contact the Source's other Feed Management Service next to see what feeds are offered there Step 3: Acquire Authorization (Outside TAXII) The Subscriber identifies the second of the Source's three for-pay TAXII Data Feeds as meeting their operational needs. Access to this TAXII Data Feed's content requires authorization. In this case, 15
17 authorization is achieved by paying the Source money using the web interface indicated in the Message field in the Feed Information Response. The Subscriber goes to this web site and provides a credit card number. At the same time, the Source and Subscriber would need to arrange for a way for the Subscriber to authenticate when communicating with the Source. For this example, it is assumed that the Source has the Subscriber establish a username and password combination for this purpose. Alternatively, they could have used certificate-based authentication mechanisms or some other means of authentication provided both parties supported it Step 4: Subscription Management Exchange The Subscriber now seeks to establish a subscription to their chosen TAXII Data Feed. The Subscriber contacts the same Feed Management Service on the Source and sends a Manage Feed Subscription Request message with an action of SUBSCRIBE (see Figure 8). The Subscriber provides the relevant authentication information, transported using the enveloping HTTP Request. The Source validates the authentication information and that the authenticated ability is permitted to subscribe to the given TAXII Data Feed and then responds with a Managed Feed Subscription Response (see Figure 9). POST /feeds/pay HTTP/1.1 Host: taxiiserver.company.com Accept: application/xml Content-Type: application/xml Content-Length: 578 User-Agent: TAXII client application X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_SubscriptionManagementRequest xmlns=" message-id="a847 98be ffe8 40ee 3722 c b d377"> <feed-name>gold</feed-name> <action>subscribe</action> <subscription> <delivery-method>taxii_https_binding_1.0</delivery-method> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <send-to> </subscription> </TAXII_SubscriptionManagementRequest> Figure 8 - TAXII Subscription Management Request Message 16
18 HTTP/ OK Content-Type: application/xml Content-Length: 758 Date: Wed, 21 Nov :12:31 GMT X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_SubscriptionManagementResponse xmlns=" message-id="984987de-feaa-95ff-894c-ccb cf67" in-response-to="a847 98be ffe8 40ee 3722 c b d377"> <feed-name>gold</feed-name> <message>thank you for your business. Your subscription is paid up for 6 months.</message> <subscription subscription-id="customer.com-jgk8h84bf"> <delivery-method>taxii_https_binding_1.0</delivery-method> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <send-to> </subscription> </TAXII_SubscriptionManagementResponse> Figure 9 - TAXII Subscription Management Response Message If there was a problem with the Source's request, the Source would respond with a TAXII Error Message. This could include the situation where validating the Subscriber's request would take longer than the timeout of the enveloping HTTP session. In this case, the Error Message type would be PENDING and be accompanied by a timestamp indicating when the Subscriber could repeat their request. At that time, the Source estimates they will have determined if the request is valid and can have a ready response when the Subscriber repeats their request. Note that the Source's response assigns a Subscription ID to this successfully-requested subscription. This Subscription ID would be used in subsequent requests to manage this subscription, as well as with any attempts to poll to receive subscription content. For this example, the Subscriber seeks to have the Source deliver TAXII Data Feed content to the Subscriber's Inbox Service using push messaging. 17
19 2.3.5 Step 5a: Data Push Exchange When the Source wishes to provide content associated with a TAXII Data Feed, it uses a TAXII Client to send a STIX Message (see Figure 10) to each Subscriber's Inbox Service. Note that, in our example, the Subscriber authenticates to the Source by providing a username and password. The Inbox Service cannot do this using an HTTP envelope since it is not initiating the connection. As such, the Source would need to trust that the Subscriber correctly provided the address of their Inbox Service. If certificate-based authentication was used, a TLS handshake could authenticate the identity of the Inbox Service. POST taxii/inbox HTTP/1.1 Host: Accept: application/xml Content-Type: application/xml Content-Length: 344 User-Agent: TAXII Feed Pusher 1000 (A TAXII Client) X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_STIXMessage xmlns=" message-id="984987de-feaa-95ff-894c-b de7d6a"> <subscription-id>customer.com-jgk8h84bf</subscription-id> <content-binding>stix_xml_1.0</content-binding> <STIX xmlns=" </TAXII_STIXMessage> Figure 10 - TAXII STIX Message Note that the content itself might be changed or elided by the Source to reflect data dissemination policies. For example, certain information might be limited to dissemination to members of particular communities and, if the Subscriber had not demonstrated membership, this information would need to be omitted from any push to the Subscriber. For the sake of this example, the actual STIX content has been removed since the details of the STIX document are outside the scope of TAXII. The Subscriber's Inbox Service receives the STIX Message and the STIX content is passed along to the relevant mechanisms that process structured cyber threat information Step 5b: Feed Poll Exchange If the Subscriber had chosen to use polling rather than have the Source push content to their Inbox Service, the Subscriber would need to utilize a Feed Poll Exchange to retrieve content. Alternately, some Sources might allow Subscribers to poll on any established Subscription as a means of retrieving older 18
20 data or to retrieve new data before a Source's regular pushes sent it out. If the Subscriber wished to poll the Source, it would send a Poll Request Message (see Figure 11) to the Source's Poll Server. Two timestamp fields bound the range of material to be collected in response to a Poll Request Message. A Subscriber might choose, for their first Poll Request, to omit these fields, thus requesting all material currently in the Source's TAXII Data Feed. For this example, the beginning timestamp is provided, indicating a lower bound to the collection, but the second timestamp is omitted, indicating a lack of an upper bound. While a Source controls the exact meaning of the timestamps used in its TAXII Data Feeds, a conventional interpretation of this would be, "provide all content newer than the given time." The Subscriber would need to provide authentication information with this request. POST /feeds/pay HTTP/1.1 Host: taxiiserver.company.com Accept: application/xml Content-Type: application/xml Content-Length: 336 User-Agent: TAXII client application X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_PollRequest xmlns=" message-id="a847 98be ffe8 40ee 3722 c b d377"> <feed-name>gold</feed-name> <begin-timestamp> t00:00:00z</begin-timestamp> <subscription-id>customer.com-jgk8h84bf</subscription-id> </TAXII_PollRequest> Figure 11 - TAXII Poll Request 19
21 HTTP/ OK Content-Type: application/xml Content-Length: 518 Date: Mon, 10 Dec :52:22 GMT X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_PollResponse xmlns=" message-id="984987de-feaa-95ff-894c-800f7eaca647a6a" in-response-to="a847 98be ffe8 40ee 3722 c b d377"> <begin-timestamp> t00:00:00z</begin-timestamp> <end-timestamp> t14:43:34z</end-timestamp> <subscription-id>customer.com-jgk8h84bf</subscription-id> <content-binding>stix_xml_1.0</content-binding> <STIX xmlns=" </TAXII_PollResponse> Figure 12 - TAXII Poll Response The Source's Poll Service receives this request, verifies the authentication information and that the poll request is valid. The Source then collects the indicated information and formats it into a Poll Response Message (see Figure 12), which is then returned to the Subscriber. Note that the Poll Response Message includes a Begin Timestamp value that matches the corresponding field in the Poll Request Message (indicating that the Source used the requested lower bound for its data collection) but also includes an End Timestamp value. The latter indicates the upper bound of the returned collection. When the Subscriber makes subsequent poll requests, they can use this timestamp, incremented by a minimal value (e.g., T14:43:34.001Z), as the lower bound to ensure that they do not pull the same content twice but that they also do not miss any provided content. 3 An Example of TAXII Support for Peer-to-Peer Sharing This section provides a very simple example of how a minimal implementation of TAXII might be used by a community of users utilizing a Peer-to-Peer sharing model. In a Peer-to-Peer model, individual community members share directly with each other rather than having all content disseminated from a central clearing house. Figure 13 shows a sample Peer-to-Peer sharing model 20
22 Peer D Peer C Peer E Peer A Peer B Figure 13 - Peer-to-Peer Sharing Model In this example, it is assumed that a sharing community has an agreement as to what information each member will share. To minimize infrastructure requirements for each Peer in the group, the decision is made to host a single Discovery Service for the entire sharing community. Every Peer in the community, using procedures outside the scope of TAXII, registers an Inbox Service with this Discovery Service. When any community member has new information to share with the community, that member uses the Discovery Service to get the list of all Inbox Services within the community and then sends a STIX Message containing the new information to each of these Inbox Services. This use of TAXII obviates any need for TAXII Data Feeds or Feed Management Services - instead, community members understand that any new information automatically gets shared to every Inbox Service registered on the communal Discovery Service. 3.1 The Participants In this model all Peers serve both as TAXII Producers and Consumers, sending and receiving content. In this particular example, there is also a Discovery Service hosted somewhere. All community members would know of this Discovery Service and have access to it. (For privacy reasons, the Discovery Service would likely require all Discovery Requests to be authenticated.) This Discovery Service could be hosted by one of the Peers within the community or it could be an independent entity. In this example, the latter is assumed. 3.2 Initial Preparation Prior to a TAXII exchange, all Peers in the sharing community must implement TAXII. The community, however, made the decision to minimize the impact of this requirement. As such, all Peers must implement an Inbox Service as well as a TAXII Client capable of interacting with the community's central Discovery Service as well as all community Inbox Services. There are no other requirements on a TAXII implementation that this sharing arrangement imposes. Specifically, there is no need for any of the individual participants to implement Feed Management Services or Poll Services, and only the single instance of the Discovery Service is required. 21
23 Moreover, this sharing arrangement does not require any understanding of TAXII Data Feeds. Since all community members automatically share with all other community members, there is no need to subscribe to TAXII Data Feeds or even to organize data according to TAXII Data Feeds. 3.3 A Sample Peer-to-Peer Interaction This section looks at the specific TAXII Message Exchanges that could be used to support interactions between Peers in this sharing community. For this example, it is assumed that the identified Peers are already community members and that all community members have an entry on the Discovery Service that identifies their Inbox Service. How prospective members might join such a sharing community is beyond the scope of TAXII. Peer D Peer C Communal Discovery Service Peer A Peer B Discovery Service Peer gets a list of all community Inbox Services TAXII Client 1 Communal Discovery Service Inbox Service A Peer B pushes content to other Peers Inbox Service C TAXII Client 2 Inbox Service D Peer B Inbox Service... Figure 14 - Example Peer-to-Peer Sharing Exchange Figure 14 shows an example of how information would be shared using this model. In this example, Peer B develops some cyber threat information it wishes to share with the other members of its sharing community. It first contacts the communal Discovery Service and from it receives a list of current Inbox 22
24 Services for the sharing community. It then initiates a Data Push Exchange with each of these Inbox Services, pushing the new content to each Peer in the community. The following sections look at the messages of both of these sets of exchanges Step 1: Discovery Exchange In this exchange, Peer B contacts the communal Discovery Service to collect latest set of contact information for the Inbox Services for the members of the sharing community. (See Figure 15) The communal Discovery Service responds with a list of the Inbox Services of community members. (See Figure 16) GET /TaxiiDiscovery/?message_type=discovery_request &message_id=a84798beffe840ee3722c893288bd375 HTTP/1.1 Host: serviceregistry.sharinggroupcoordinator.com Accept: application/xml Content-Type: application/xml User-Agent: Sharegroup Client App X-TAXII-Accept: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 Figure 15 - TAXII Discovery Request Message 23
25 HTTP/ OK Content-Type: application/xml Content-Length: 2865 Date: Wed, 14 Nov :22:13 GMT X-TAXII-Content-Type: TAXII_1.0/TAXII_XML_BINDING_1.0 X-TAXII-Protocol: TAXI_HTTPS_BINDING_1.0 <?xml version="1.0" encoding="utf-8"?> <TAXII_DiscoveryResponse xmlns=" message-id="984987de-feaa-95ff-894c-cbcc " in-response-to="a84798beffe840ee3722c893288bd375"> <service-instance service-type="inbox" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <service-address> <message>abc Corp.</message> </service-instance> <service-instance service-type="inbox" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <service-address> <message>bobcom</message> </service-instance> <service-instance service-type="inbox" service-version="taxii_1.0"> <protocol-binding>taxii_http_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <service-address> <message>corp.com</message> </service-instance> <service-instance service-type="inbox" service-version="taxii_1.0"> <protocol-binding>taxii_https_binding_1.0</protocol-binding> <message-binding>taxii_xml_binding_1.0</message-binding> <content-binding>stix_xml_1.0</content-binding> <service-address> <message>digitaldata Corp.</message> </service-instance>... </TAXII_DiscoveryResponse> Figure 16 - TAXII Discovery Response Message Note that, unlike the previous example, the Discovery Response Message does not list the Discovery Service itself. What to include in a Discovery Response Message is at the discretion of the information 24
The Problem Attackers are reusing attacks (because they work) Defenders are collecting and/or sharing information, but Often a manual process (copy-paste from a PDF) Different sources provide different
EVOLUTION OF CYBER THREAT INTELLIGENCE BRET JORDAN CISSP Director of Security Architecture and Standards ENISA 2015-02-24 1 Evolution of Cyber Threat Intelligence About me Bret Jordan 20+ years in network
Comparison of WAP Push and Short Message Service (SMS) About Openwave Openwave Systems Inc. (Nasdaq: OPWV) is the worldwide leader of open IP-based communication infrastructure software and applications.
CA Nimsoft Service Desk Configure Outbound Web Services 7.13.7 Legal Notices Copyright 2013, CA. All rights reserved. Warranty The material contained in this document is provided "as is," and is subject
OpenScape Voice V8 Application Developers Manual Programming Guide A31003-H8080-R100-2-7620 Our Quality and Environmental Management Systems are implemented according to the requirements of the ISO9001
The Web Security Authority. TM Active Directory Integration with Blue Coat NOTE: This techbrief is applicable when using NTLM under Windows 2000 Server. Introduction Windows 2000 server utilizes Active
Trait-based Authorization Mechanisms for SIP Based on SAML Douglas C. Sicker, University of Colorado Boulder Hannes Tschofenig, Siemens Jon Peterson, Neustar Abstract - This paper presents a method for
Network Working Group Request for Comments: 4579 BCP: 119 Category: Best Current Practice A. Johnston Avaya O. Levin Microsoft Corporation August 2006 Status of This Memo Session Initiation Protocol (SIP)
Deltek Touch Time & Expense for GovCon User Guide for Triumph November 25, 2014 While Deltek has attempted to verify that the information in this document is accurate and complete, some typographical or
Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence Service Oriented Architecture SOA and Web Services John O Brien President and Executive Architect Zukeran Technologies
Common definitions and specifications for OMA REST interfaces Candidate Version 1.0 11 Jan 2011 Open Mobile Alliance OMA-TS-REST_Common-V1_0-20110111-C OMA-TS-REST_Common-V1_0-20110111-C Page 2 (20) Use
Using SAML for Single Sign-On in the SOA Software Platform SOA Software Community Manager: Using SAML on the Platform 1 Policy Manager / Community Manager Using SAML for Single Sign-On in the SOA Software
SAML AS AN SSO STANDARD FOR CUSTOMER IDENTITY MANAGEMENT How to Create a Frictionless, Secure Customer Identity Management Strategy PART 1: WHAT IS SAML? SAML in Context Security Assertion Markup Language
Fundamentals of Web Programming a Universal Description, Discovery, and Integration Teodor Rus email@example.com The University of Iowa, Department of Computer Science a Copyright 2009 Teodor Rus. These
Integration of Hotel Property Management Systems (HPMS) with Global Internet Reservation Systems If company want to be competitive on global market nowadays, it have to be persistent on Internet. If we
Chapter 17 Transport-Level Security Web Security Considerations The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets The following characteristics
Technical Interface Description Version 2.4.1 28.04.2015 Table of Contents 1 Introduction... 6 1.1 Preamble... 6 1.2 Structure of the Document... 6 1.3 Referenced Documents... 7 1.4 List of Abbreviations...
Deployment Guide Deploying the BIG-IP System with Microsoft Windows Server 2003 Terminal Services Deploying the BIG-IP LTM system and Microsoft Windows Server 2003 Terminal Services Welcome to the BIG-IP
vcloud Air Platform Programmer's Guide vcloud Air OnDemand 5.7 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition.
The Proxy Server THE PROXY SERVER 1 1 PURPOSE 3 2 USAGE EXAMPLES 4 3 STARTING THE PROXY SERVER 5 4 READING THE LOG 6 2 1 Purpose The proxy server acts as an intermediate server that relays requests between
White Paper Securing and Integrating File Transfers Over the Internet While the integrity of data during transfer has always been a concern the desire to use the Internet has highlighted the need to secure
Divide and Conquer Real World Distributed Port Scanning Ofer Maor CTO Hacktics 16 Feb 2006 Hackers & Threats I, 3:25PM (HT1-302) Introduction Divide and Conquer: Real World Distributed Port Scanning reviews
Title page Alcatel-Lucent 5620 SERVICE AWARE MANAGER 13.0 R7 APPLICATION API DEVELOPER GUIDE 3HE-10590-AAAA-TQZZA Issue 1 December 2015 Legal notice Legal notice Alcatel, Lucent, Alcatel-Lucent and the
Documentum Content Distribution Services TM Administration Guide Version 5.3 SP5 August 2007 Copyright 1994-2007 EMC Corporation. All rights reserved. Table of Contents Preface... 7 Chapter 1 Introducing
About the VM-Series Firewall Palo Alto Networks VM-Series Deployment Guide PAN-OS 6.0 Contact Information Corporate Headquarters: Palo Alto Networks 4401 Great America Parkway Santa Clara, CA 95054 http://www.paloaltonetworks.com/contact/contact/
Technical white paper Integrated Billing Solutions with HP CSA 4.00 Table of Contents Introduction... 2 Part 1. HP CSA Concepts... 2 Part 2. Billable Service Conditions... 4 Part 3. Billable Intervals...
Napster and Gnutella: a Comparison of two Popular Peer-to-Peer Protocols Anthony J Howe Supervisor: Dr Mantis Cheng University of Victoria February 28, 2002 Abstract This article presents the reverse engineered
Paper AD08 Using web service technologies for incremental, real-time data transfers from EDC to SAS Andrew Newbigging, Medidata Solutions Worldwide, London, UK ABSTRACT Data collected in EDC systems is
OAuth 2.0 Developers Guide Ping Identity, Inc. 1001 17th Street, Suite 100, Denver, CO 80202 303.468.2900 Table of Contents Contents TABLE OF CONTENTS... 2 ABOUT THIS DOCUMENT... 3 GETTING STARTED... 4
sessionx Desarrollo de Aplicaciones en Red José Rafael Rojano Cáceres http://www.uv.mx/rrojano Web Applications 1 2 Content History (1) History Http CGI Web Tiers ARPANet Email, Ftp, IRC, news Explosive
1 Table of Contents Introduction... 4 System and Hardware Requirements... 4 Supported Operating Systems... 4 Microsoft SQL Server... 4 Microsoft.NET Framework 4.0... 4 Microsoft Internet Information Services
DEPLOYMENT GUIDE Version 1.1 Deploying the BIG-IP LTM v10 with Citrix Presentation Server 4.5 Table of Contents Table of Contents Deploying the BIG-IP system v10 with Citrix Presentation Server Prerequisites
Installation and Administration Guide Release 8 This installation guide will walk you through how to install and deploy Conga Composer, including recommended settings for the application. Contact Support:
Introduction to Testing Webservices Author: Vinod R Patil Abstract Internet revolutionized the way information/data is made available to general public or business partners. Web services complement this
Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and
Message Containers and API Framework Notices Copyright 2009-2010 Motion Picture Laboratories, Inc. This work is licensed under the Creative Commons Attribution-No Derivative Works 3.0 United States License.
The Alfresco API Contents The Alfresco API... 3 How does an application do work on behalf of a user?... 4 Registering your application... 4 Authorization... 4 Refreshing an access token...7 Alfresco CMIS
Vehicle Monitoring Quick Reference Guide Powered by Delphi Welcome You re about to experience a powerful device that will deliver a new level of convenience and peace of mind with your vehicle. When combined
INT0697_150625 Setting up an AS4 system V1r0 1 Setting Up an AS4 System 2 Version 1r0 ENTSOG AISBL; Av. de Cortenbergh 100, 1000-Brussels; Tel: +32 2 894 5100; Fax: +32 2 894 5101; firstname.lastname@example.org, www.entsog.eu,
BlackBerry Enterprise Service 10 Version: 10.2 Configuration Guide Published: 2015-02-27 SWD-20150227164548686 Contents 1 Introduction...7 About this guide...8 What is BlackBerry Enterprise Service 10?...9
Ben Ramsey php works About Me: Ben Ramsey Proud father of 7-month-old Sean Organizer of Atlanta PHP user group Founder of PHP Groups Founding principal of PHP Security Consortium Original member of PHPCommunity.org
Installation and Configuration Guide Installation and configuration guide Adding X-Username support to Forward and Reverse Proxy TMG Servers Published: December 2010 Applies to: Winfrasoft X-Username for
Secure XML API Integration Guide (with FraudGuard add in) Document Control This is a control document DESCRIPTION Secure XML API Integration Guide (with FraudGuard add in) CREATION DATE 02/04/2007 CREATED
This Specification is provided for future development work within onem2m only. The Partners accept no liability for any use of this Specification. The present document has not been subject to any approval
XML Document Management Architecture Candidate Version 2.0 02 Dec 2010 Open Mobile Alliance OMA-AD-XDM-V2_0-20101202-C OMA-AD-XDM-V2_0-20101202-C Page 2 (30) Use of this document is subject to all of the
CEN 448 Security and Internet Protocols Chapter 17 Web Security Dr. Mostafa Hassan Dahshan Computer Engineering Department College of Computer and Information Sciences King Saud University email@example.com
InternetVista Web scenario documentation Version 1.2 1 Contents 1. Change History... 3 2. Introduction to Web Scenario... 4 3. XML scenario description... 5 3.1. General scenario structure... 5 3.2. Steps
Pre-configured AS2 Host Quick-Start Guide Document Version 2.2, October 19, 2004 Copyright 2004 Cleo Communications Refer to the Cleo website at http://www.cleo.com/products/lexihubs.asp for the current
Network Technologies Glenn Strong Department of Computer Science School of Computer Science and Statistics Trinity College, Dublin January 28, 2014 What Happens When Browser Contacts Server I Top view:
Evoko Room Manager System Administrator s Guide and Manual 1 1. Contents 1. Contents... 2 2. Read this first! Introduction to this Guide... 6 3. User Guide... 6 4. System Architecture Overview... 8 ----
LogMeIn Hamachi Getting Started Guide Contents What Is LogMeIn Hamachi?...3 Who Should Use LogMeIn Hamachi?...3 The LogMeIn Hamachi Client...4 About the Relationship Between the Client and Your LogMeIn
Due to the fact that nearly all businesses have websites (as well as government agencies and individuals) a large enthusiasm exists for setting up facilities on the Web for electronic commerce. Of course
Web Services Implementation: The Beta Phase of EPA Network Nodes Connie Dwyer and Chris Clark U.S. Environmental Protection Agency, 1200 Pennsylvania Avenue, N. W., Washington, D.C. firstname.lastname@example.org
HP ProCurve Manager Plus Getting Started Guide The all-in-one solution for managing HP ProCurve networks HP ProCurve Manager Plus Getting Started Guide Copyright 2003 Hewlett-Packard Development Company,
Safeguard Ecommerce Integration / API Product Manual Version 3 Revision 1.11 Table of Contents 1. INTRODUCTION... 4 1.1 Available commands... 4 2. HOW THE ADMINISTRATION SYSTEM IS EXPECTED TO BE USED OPERATIONALLY...
CyberSource PayPal Services Implementation Guide Simple Order API SCMP API September 2015 CyberSource Corporation HQ P.O. Box 8999 San Francisco, CA 94128-8999 Phone: 800-530-9095 CyberSource Contact Information
DOCUMENT HISTORY DOCUMENT HISTORY Version Release Date Description 0.01 24/01/2013 Initial draft 0.02 01/02/2013 Review 1.00 07/08/2013 Version 1.00 -v1.00.doc Page 2 of 17 TABLE OF CONTENTS 1 Introduction...
www.novell.com/documentation Jobs Guide Identity Manager 4.0.1 February 10, 2012 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation,
DEPLOYMENT GUIDE Deploying the BIG-IP LTM v9.x with Microsoft Windows Server 2008 Terminal Services Deploying the BIG-IP LTM system and Microsoft Windows Server 2008 Terminal Services Welcome to the BIG-IP
RS MDM 2009 Integration Guide This document provides the details about RS MDMCenter integration module and provides details about the overall architecture and principles of integration with the system.
Setup Guide Revision B McAfee SaaS Email Archiving for Microsoft Exchange Server 2010 COPYRIGHT Copyright 2015 McAfee, Inc., 2821 Mission College Boulevard, Santa Clara, CA 95054, 1.888.847.8766, www.intelsecurity.com
HP Data Protector Integration with Autonomy LiveVault Introducing cloud backup for HP Data Protector environments Technical white paper Table of contents Summary... 2 Introduction... 2 Integration concepts...
Deploying System Center 2012 R2 Configuration Manager This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Administration Guide BlackBerry Enterprise Service 12 Version 12.0 Published: 2015-01-16 SWD-20150116150104141 Contents Introduction... 9 About this guide...10 What is BES12?...11 Key features of BES12...
A Standards-based Mobile Application IdM Architecture Abstract Mobile clients are an increasingly important channel for consumers accessing Web 2.0 and enterprise employees accessing on-premise and cloud-hosted
Kaspersky Security Center 10 Getting Started A P P L I C A T I O N V E R S I O N : 1 0 M A I N T E N A N C E R E L E A S E 1 Dear User, Thank you for choosing our product. We hope that this document will
FernUniversität in Hagen: Certification Authority (CA) Certification Practice Statement VERSION 1.1 Ralph Knoche 18.12.2009 Contents 1. Introduction... 4 1.1. Overview... 4 1.2. Scope of the Certification
Fairsail REST API: Guide for Developers Version 1.02 FS-API-REST-PG-201509--R001.02 Fairsail 2015. All rights reserved. This document contains information proprietary to Fairsail and may not be reproduced,
SIF 3: A NEW BEGINNING The SIF Implementation Specification Defines common data formats and rules of interaction and architecture, and is made up of two parts: SIF Infrastructure Implementation Specification
TIBCO Spotfire Automation Services 6.5 User s Manual Revision date: 17 April 2014 Important Information SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO
Research on the Model of Enterprise Integration with Web Services XIN JIN School of Information, Central University of Finance& Economics, Beijing, 100081 China Abstract: - In order to improve business
HOST EUROPE CLOUD STORAGE REST API DEVELOPER REFERENCE REST API REFERENCE REST OVERVIEW Host Europe REST Storage Service uses HTTP protocol as defned by RFC 2616. REST operations consist in sending HTTP
INTEGRATE SALESFORCE.COM SINGLE SIGN-ON WITH THIRD-PARTY SINGLE SIGN-ON USING SENTRY A GUIDE TO SUCCESSFUL USE CASE Legal Marks No portion of this document may be reproduced or copied in any form, or by
Software Architecture Document Project Management Cell 1.0 1 of 16 Abstract: This is a software architecture document for Project Management(PM ) cell. It identifies and explains important architectural
Department of Computer Science Imperial College London CERN School of Computing (icsc), 2005 Geneva, Switzerland 1 Fundamental Concepts Architectures & escience example 2 Distributed Computing Technologies
VitalQIP DNS/DHCP & IP Address Management Software and Appliance Solution May 2011 7.3 Version 1 Copyright 2011 Alcatel-Lucent 1 Table of Contents 1. Document Purpose... 3 2. What s New in VitalQIP 7.3?...
Integration Guide for Data Originators of CCR Documents Version 1.0 November 11, 2010 Integration Guide for Data Originators of CCR Documents Revision History Date Version Description Author October 29,
CA Data Protection Content Provider Development Guide Release 15.0 This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the Documentation
Load testing with WAPT: Quick Start Guide This document describes step by step how to create a simple typical test for a web application, execute it and interpret the results. A brief insight is provided