Everything about TAXII

HS SEDI is a trademark of the U.S. Department of Homeland Security (DHS)The HS SEDI FFRDC is managed and operated by The MITRE Corporation for

DHS

7/8/2014

TAXII: An Overview

Approved for Public Release; Distribution Unlimited: 12-4167


DHS

Code

Fork us on GitHub– https://github.com/TAXIIProject/

Python implementations– https://github.com/TAXIIProject/libtaxii

Python library for serializing/deserializing XML messages, TAXII Clients

– YETI – Proof of concept TAXII Server Python/Django

– Installable via pip from PyPi

| 2 |

https://github.com/TAXIIProject/

https://github.com/TAXIIProject/

https://github.com/TAXIIProject/libtaxii




DHS

What is TAXII?

Trusted Automated eXchange of Indicator Information Standardizes exchange of cyber threat information– Can exchange other information, too

A set of specifications any software can implement

TAXII is NOT– A specific sharing program

but sharing programs can use it

– Software but software can use it to share information

– Mandate particular trust agreements or sharing instead, use it to share what you want with the parties you

choose

| 3 |


DHS

Why was TAXII Created?

Driven by DHS CS&C NCCIC operational need to effectively share cyber threat information with a diverse community.– Existing standards did not solve the problem

An open community effort led by DHS– Developed with strong participation from a diverse set of

government and industry stakeholders. Ensures that TAXII addresses real challenges in real environments

In operational use today.

| 4 |


DHS

Design Philosophy

Facilitate rather than re-architect existing sharing arrangements

Do not force inclusion of undesired capabilities Sharing communities each have their own character

– a one-size-fits-all approach will be more disruptive than beneficial– Do not impose a single sharing model architecture

| 5 |


DHS

Flexible Sharing Models

Most sharing models are variants of these three basic models– TAXII can support

participation in any of thesemodels or multiple modelssimultaneously

| 6 |

Source

Subscriber

Subscriber Subscriber

Subscriber

Hub

Spoke(Consumer only)

Spoke(Consumer & Producer)

Spoke(Producer only)

Spoke(Consumer & Producer)

Peer E

Peer D Peer C

Peer B

Peer A


DHS

TAXII Features

Minimal requirements imposed on data consumers– Does not require data consumers to field internet services or

establish a particular security capability Minimal data management requirements on data producers– Does not require use of particular data management technologies

or constrain how producers manage access to their data Flexible sharing model support– Does not force a particular sharing model on users

Appropriately secure communication– Supports multiple security mechanisms without forcing adoption

of unnecessary measures Push and Pull content dissemination– Users can exchange data using either or both models

Flexible protocol and message bindings– Does not require a particular network protocol or message format

| 7 |


DHS

TAXII Services

TAXII defines four Services– Discovery – A way to learn what services an entity

supports and how to interact with them– Collection Management – A way to learn about and

request subscriptions to Data Collections– Inbox – A way to receive pushed content (push

messaging)– Poll – A way to request content (pull messaging)

Each service is optional – implement only the ones you wish– You can have multiple instances of each service

Services can be combined in different ways for different sharing models

| 8 |


DHS

TAXII Data Collections

TAXII does not dictate how data producers store or organize their data…

…but TAXII requires some common handle for communication TAXII Data Collection – a producer-dictated organization of

their data– A Data Collection can be either a Data Feed (ordered data) or Data

Set (unordered data)– A given data record might exist in one or more TAXII data collections– Producers decide what data collections represent. Examples:

Topic – e.g., a collection for spear-phishing, a collection for botnets, etc. Subject – e.g., a collection for each identified STIX campaign Access – e.g., a collection for gold-level subscribers, a collection for silver-

level, etc. Or producer might just have one collection with everything in it

In TAXII, all solicited data distribution (push or pull) occurs relative to a TAXII Data Collection

| 9 |


DHS

Query

Query is an extension point in TAXII We have defined the ‘TAXII Default Query’– You can define your own if you want

TAXII Default Query– Defines what a Query looks like, processing rules, and how

to express which query capabilities are supported– Uses Target (e.g., a field) and Test (e.g., “equals 4”)

constructs that can be combined using logical operators (e.g., AND/OR) to construct more complex queries

A Query can be a Poll Parameter or a Subscription Parameter

Query results are expressed in the same way other information is expressed (i.e., Poll Response or Inbox Message) | 10

|


DHS

Hub & Spoke Example

| 11 |

Discovery PollInbox

Collect.Manage

.

HubSpoke 1

Spoke 2

Spoke 3

Spoke 4

Get connection

info

Subscribe to data

collections

Client

Push new data to the

hub

Pull recent data from the

hub

Push recent data to a

spoke


DHS

TAXII Specifications and Documentation

TAXII Overview– Describes the scope and direction of TAXII

Services Specification– Defines TAXII Services, TAXII Messages (conceptually), and

TAXII Message Exchanges (conceptually). XML Message Binding Specification– Defines the XML format for TAXII Messages

HTTP Protocol Binding Specification– Defines the HTTP/HTTPS transport for TAXII Message

Exchange Default Query Specification– Defines a query format and processing rules.

Content Binding Reference– Lists common Content Binding IDs for use within TAXII.

| 12 |


DHS

TAXII Specifications and Documentation

| 13 |


DHS

Message and Protocol Bindings

TAXII Services Specification defines TAXII Concepts– Which fields must/may be present in a TAXII Message– Allowable ordering of TAXII Messages

TAXII 1.1 Bindings map concepts to specific technologies (e.g., XML, HTTP)– XML/HTTPS is what you should use unless you have a

requirement not to– Future alternatives for XML and HTTP/HTTPS could be defined

Additional bindings gives organizations with strict network/format requirements ability to still use TAXII– However, when using differing bindings, direct interoperation is

not possible– Indirect interoperation is possible because all bindings can be

mapped to the same core message model Gateways can provide automated translation between bindings

| 14 |


DHS

Open Source Projects

We’ve done some implementation work for you libtaxii– python APIs for TAXII XML Messages and TAXII HTTP/HTTPS

Clients YETI– proof of concept TAXII Server (python/Django)

| 15 |


DHS

For more information

TAXII Website– Contains official releases and other info– http://taxii.mitre.org/

Sign up for the TAXII Discussion and Announcement mailing lists– http://taxii.mitre.org/community/registration.html– Or message us directly: [email protected]

TAXII-related software can be found on GitHub– https://github.com/TAXIIProject

| 16 |

http://taxii.mitre.org/

http://taxii.mitre.org/community/registration.html

http://taxii.mitre.org/community/registration.html

mailto:[email protected]

https://github.com/TAXIIProject

https://github.com/TAXIIProject


DHS

| 17 |

TAXII Services


DHS

Discovery Service

Allows clients to discover what TAXII Services the server offers

Message Exchange:– Client sends a Discovery Request

The Discovery Request does not have any parameters

– Server responds with a Discovery Response that lists TAXII Services Includes service type (e.g., Inbox), address, description, etc.

Server can elide services– This is a theme in TAXII

| 18 |


DHS

Inbox Service

Hosted by data consumers to receive pushed content Basically a listener for incoming content Message Exchange:– Client sends an Inbox Message containing 0 or more

Content Blocks– Server responds with a Status Message (indicating

Success or an error condition)

| 19 |


DHS

Poll Service

Hosted by data producers to allow consumers to Poll data

Consumers request updates relative to a TAXII Data Collection

Message Exchange:– Client sends Poll Request (contains Data Collection name,

optional query, etc)– Server responds with a Poll Response containing 0 or more

Content Blocks or a Status Message Poll Requests can specify various parameters– Query– Response type (Count or Full)– Acceptable response types (e.g., STIX 1.1.1)– … and a few more

| 20 |


DHS

TAXII Collection Management Service

Hosted by data producers to provide information on Data Collections and/or process Subscriptions

Can offer one or both of two message exchanges Message Exchange (1/2): Collection Information

Exchange– Client sends a Collection Information Request (no

parameters)– Server responds with a Collection Information Response

listing Data Collections a Status Message. Information Response includes: Data Collection names and descriptions How TAXII Data Collection content can be accessed (“pull” or

indicate delivery protocols) Any other information about a TAXII Data Collection (e.g.,

membership requirements, payment requirements, etc.)| 21

|


DHS

TAXII Collection Management Service(cont’d) Message Exchange (2/2): Subscription Management

Exchange– Client sends a Manage Collection Subscription Request

requesting a status, create, cancel, pause, or resume action on a subscription Create Subscription requests can include a query

– Server responds with a Manage Collection Subscription Response or Status Message

– Note this just deals with arranging subscriptions, not actual data dissemination

TAXII does not specify the process for deciding whether to allow the requested action to occur nor how the action manifests

Note this just deals with arranging subscriptions, not actual data dissemination

| 22 |


DHS

In Summary

Discovery Service – Discover TAXII Services Inbox Service – Push data Poll Service – Poll Data Collection Management Service – Request information

on Collections, Manage Subscriptions

| 23 |


DHS

| 24 |

Source/Subscriber Walkthrough


DHS

Background

One possible way to use TAXII to implement Source/Subscriber– Others may make different choices

Assume an existing sharing arrangement– A vendor (the source) publishes threat alerts as

information becomes known– Customers (subscribers) can pay to receive these daily

updates Multiple levels of access depending on contract costs

– Currently, customers log into the vendor web site to view updates

| 25 |


DHS

Step 1: Source Organizes its Data

Vendor organizes data records into TAXII Data Collections– Decides on “contract level” for collections

Many records will be present in all collections, but some fields may be stripped before dissemination

– All Data Collections are Data Feeds The vendor wants the data to be ordered so that consumers can

request only the most recent data

– Access to a feed contingent upon the purchasing of a contract Vendor labels all data within each TAXII Data Feed with a

timestamp– Decides to use the time of posting as that timestamp

More than one data record may have the same timestamp – not a problem

A single record could have the same timestamp in all data feeds – not a requirement

| 26 |


DHS

Step 2a: Source Implements TAXII Services

Decides to implement a Collection Management Service– Collection Information Requests

Lists available collections Explain what information is provided via each Data Collection (i.e.,

contract levels) Reference to site where one can purchase necessary contracts

– Collection Management Requests Forward management requests to back-end for comparison to

purchased contracts

Decides to implement a Poll Service– Give customers the option to pull content from a collection

Decides to interface with Customers’ Inbox Services– Support pushing content to customer Inbox Services

Decides NOT to implement a Discovery Service– Vendor decides to continue publishing this information using HTML

| 27 |

MUST do at least

one


DHS

Step 2b: Subscriber Implements TAXII Service

May implement an Inbox Service– If customer wishes have updates pushed, must

implement Inbox– Inbox listens to appropriate port for connections

In TAXII 1.1, this would be a (truncated) HTTP server

– May avoid implementing if all content to be pulled via Poll Service

Subscribers may interface with the Vendor’s TAXII Poll Service for pull messaging

For this design, subscribers must interface with the Vendor’s TAXII Collection Management Service

| 28 |


DHS

Step 3: Establish Sharing Relationships

Customer contacts vendor Collection Management Service to get list of collections

Customer purchases a contract via Vendor web site– Also establishes

authentication credentials

Customer contacts vendor Collection Management Service to establish subscription– Request verified before

acceptance

| 29 |

Customer

Vendor TAXII Collection

Management Service


DHS

Step 4: Share

Content pushed to Customer’s Inbox Service

Customer pulls from Vendor’s Poll Service– Request verified before

being fulfilled

| 30 |

CustomerVendor Poll

Service

Customer Inbox

ServiceVendor


DHS

| 31 |

Hub and Spoke Walkthrough


DHS

Background

One possible way to use TAXII to implement Hub and Spoke– Others may make different choices

Assume an existing sharing arrangement– Community exists with a pre-existing intra-group

sharing agreement– Currently all threat alerts sent via e-mail to the group

mailing list Automatically re-distributed to all group members

| 32 |


DHS

Step 1a: Hub Implements TAXII Services

Decide to implement a Inbox Service– Used to receive all input from spokes (Hub does not poll)

Decide to interface with Spokes’ TAXII Inbox Services for message delivery– Support pushing of alerts to spokes

Decide to implement a Poll Service– Support spokes pulling current and/or archived alerts– Decide on only one TAXII data feed for all information– Decide timestamps = the time the alert arrives in Hub’s Inbox

Decide NOT to implement a Discovery Service– Members informed of the Hub’s services via other means

Decide NOT to implement a Collection Management Service– Spokes automatically enrolled when they join the sharing group

| 33 |


DHS

Step 1b: Spokes Implement TAXII Services

Spokes that produce data interface with the Hub’s TAXII Inbox Service

May implement an Inbox Service– If spoke wants pushed info, must implement Inbox– May avoid implementing if all content to be pulled via

Poll Service Some spokes may interface with the Hub’s TAXII

Poll Service– May avoid this use if all content to be pushed to the

spoke’s Inbox Service

| 34 |


DHS

Step 2: Share

Spoke X pushes new alert to Hub’s Inbox Service

Hub re-sends alert to all spokes that requested push notification

Hub archives alert so spokes can poll for the alert at a later time

| 35 |

Hub

X


DHS

libtaxii

Python library Supports TAXII 1.0 and TAXII 1.1 APIs for TAXII Messages APIs for TAXII Clients No server-specific functionality (but servers can and

do use the TAXII Message APIs)

| 36 |


DHS

libtaxii – Poll Request Code

| 37 |


DHS

libtaxii – Poll Request XML

| 38 |


DHS

libtaxii – Poll Response Code

| 39 |


DHS

libtaxii - Poll Response XML

| 40 |


DHS

libtaxii – TAXII Client Code

| 41 |


DHS

YETI

The name doesn’t actually mean anything Proof of concept TAXII Server Built on Python and Django (a Python web app

framework) Implements TAXII Discovery Service, Poll Service, and

Inbox Service– We are working on a query implementation

Have one deployment hosted at http://taxiitest.mitre.org

| 42 |

Technology

Everything about TAXII