Skip to content

TAXII 2.0 Use Cases

stevenjackson121 edited this page Jul 27, 2016 · 16 revisions

This page lists use cases for TAXII 2.0. Please note that these use cases have not been prioritized by the OASIS CTI TAXII SC. These all need to be fleshed out more.

Use Cases

  1. Threat Feed (private and one way)
  2. Threat Analysis and Enrichment (private and two way)
  3. Threat Sharing Public
  4. Threat Generation and Emitting but not Storing
  5. Malware Sample Sharing
  6. Weather Map - Inward Facing
  7. Weather Map - Outward Facing

Threat Feed (private and one way)

Description: An organization wants to produce and sell their threat intelligence feeds. They have an internal process that finds, vets, and creates threat intelligence and stores it somewhere in their systems. It may or may not be stored in STIX format. They want the ability to publish this threat intelligence to paid subscribers. Subscribers for this feed will NEVER be allowed to contribute back or provide data-enrichments or sightings of the data. This is a one-way feed. Organizations will want a minimal TAXII interface to allow them to easily integrate TAXII in to their existing infrastructure. Further, this organization may share this same threat data in forms other than STIX and TAXII.

Open Questions:

  1. Are the Threat Feed (private and one way), Threat Analysis and Enrichment (private and two way), and Threat Sharing Public suitable to be combined into one Use Case w/ variations?

Examples: (These probably also apply to other use cases)

Threat Analysis and Enrichment (private and two way)

Description: An organization wants to produce and distribute their threat intelligence to a closed eco-system and allow that eco-system to comment, data-enrich, add sightings, add relationships, etc to that threat intelligence. This can be as big as an ISAC or as small as a group of threat researchers inside a company.

Threat Sharing Public

Description: An organization wants to share its threat data to the general public. This threat data may need to be anonymized. The users will want to gain access to this threat data so they can use it in their own analysis systems.

Threat Generation and Emitting but not Storing

Description: An organization or device wants to generate threat intelligence and send it to a list of subscribers, either public or private in near-real time but has no ability or desire to store the threat intelligence for later retrieval. Another example of this would be devices on a network or in the cloud, may want to generate and share "emit" observables / indicators in mass, but do not have the ability nor the desire to store them for later query. Think of a layer 7 firewall or proxy that see something and wants to let other security devices in the network know about it. Or think of a cloud based sandbox that is hooked up to a honeynet and wants to send out 1 million hashes a day of things it found that were bad.

Malware Sample Sharing

Description: One organization wants to share malware samples with other partner organizations. This use case does not address sharing of analysis information - merely sending of malicious samples.

Roles/Goals:

  • Role: Sending Partner
  • Goal: Send a piece of malware to a partner organizations
  • Role: Receiving Partner
  • Goal: Receive a piece of malware from a partner organization

Preconditions:

  1. Sending and Receiving partner have access to the same group on the same TAXII Server
  2. An organization wants to send a malware sample
  3. An organization wants to receive a malware sample

Main Success Scenario:

  1. Sending partner identifies some malware
  2. Sending partner packages malware in a "safe" manner
  3. Sending partner publishes the package on a TAXII Server
  4. Receiving partner consumes the package from a TAXII Server
  5. Receiving partner unpackages malware
  6. Receiving partner adds malware to some analysis repository

Open Questions None known at this time.

Weather Map (Inward Facing)

Note: Please feel free to use this as a template for other use cases

Description: An organization (e.g., ISAC/ISAO) builds a dashboard to look "inward" at member organizations and their threat levels. For instance, each ISAC/ISAO member could regularly report an alert level (nominally, Red, Yellow, or Green) and the ISAC/ISAO could put those alert levels on a map.

Roles/Goals:

  • Role: ISAC/ISAO
  • Goal: Maintain a dashboard of member organization threat levels
  • Role: ISAC/ISAO Member Organization
  • Goal: Regularly send threat-level information to an ISAC/ISAO

Preconditions:

  1. Some ISAC/ISAO exists and has a TAXII Server
  2. One or more organizations want to submit "Threat Level" information

Main Success Scenario:

  1. Member organization has a change in threat level
  2. Member organization publishes this change on an appropriate channel
  3. ISAC/ISAO is listening on the appropriate channel and receives the message
  4. ISAC/ISAO updates the database powering their dashboard
  5. Things update on the dashboard, and people are happy.

Open Questions None known at this time.

Weather Map (Outward Facing)

Description: An organization (e.g., ISAC/ISAO) has a dashboard to look "outward" at threats that might exist in cyberspace. As a nominal illustration, consider a list of "bad" IP addresses that also have geolocation information, stored in a database. This information is displayed on a map, showing the "weather".

Roles/Goals:

  • Role: ISAC/ISAO
  • Goal: Maintain a dashboard of outward-looking (aka adversary focused) threat information
  • Role: ISAC/ISAO Member Organization
  • Goal: Submit threat information (TODO: WHY?? Contractual requirements?)

Preconditions:

  1. Some ISAC/ISAO exists and has a TAXII Server
  2. One or more organizations want to submit threat information for IPs/etc.

Main Success Scenario:

  1. Member organization identifies that an observable (e.g., IP) is "malicious" (or not)
  2. Member organization publishes this information on an appropriate channel
  3. ISAC/ISAO is listening on the appropriate channel and receives the message
  4. ISAC/ISAO updates the database powering their dashboard
  5. Things update on the dashboard, and people are happy.

Open Questions:

  1. Why would an organization spend time submitting threat information to another organization?
  2. Can/Should this scope be reduced? "Threat information" is pretty broad - does this use case only care about IPs, or is it broader?

Analysis Requests/Responses

Description: A company provides threat (e.g., malware) analysis as a service (e.g., VirusTotal). This service might be free or paid.

Roles/Goals:

  • Role: Analysis Provider
  • Goal: Provide analysis on-request to customers in an efficient manner
  • Role: Analysis Requester (e.g., customer)
  • Goal: Regularly send threat-level information to an ISAC/ISAO

Preconditions: Any?

Main Success Scenario:

  1. An organization - the analysis requester - discovers an observable (e.g., file) and would like it analyzed.
  2. The organization submits the observable for analysis
  3. The analysis provider analyzes the observable and creates analysis
  4. The analysis provider makes the analysis available to the analysis requester
  5. Optionally, the analysis provider might choose to broadcast this analysis to all customers
  6. Optionally, the analysis provider might choose to allow other customers to query this result later on (HOW?)

Open Questions

  1. How do we define what "results" are? In the wild, analysis providers have different formats and quantity of information (I think - can this be substantiated?).
  2. How would queries be performed?

Query (and Threat Storage?)

Query is a large enough subset of use cases that it is discussed separately.

Rogue TAXII Server

In this Use Case a rogue TAXII Server is spewing out incorrect data in an attempt to convince other organizations that certain relationships do not exist when in truth they do. Think of this as counterintelligence.

TAXII needs a way for consumers to crowdsource how truthful a suggested relationship is. Each TAXII server representing a namespace needs a way to share how much they trust information from another namespace, so that a consumer can crowdsource how trustworthy they believe a source is.

TAXII also needs a way of sending upvotes and downvotes for relationships, and also for information sources, so that over time consumers can determine which namespaces are the ones worth trusting, and can ignore the ones that talk 'untruths'.

Hypothesized relationships

In this Use Case a specialist threat intelligence team are tracking a particular threat group (HorseCatX). They have an inkling that there is a relationship between HorseCatX and DogFoodY, another group discovered by another Threat Intel company. TAXII needs to support the ability for a hypothesis to be sent out to others and for people to understand it is not validated data. It is a guess. There also needs to be a way of getting answers back to the producer so that they can adjust their own hypothesis and either adjust it, or confirm it.

Government wants to share intel but no-one to know it was them

In this Use Case a government organization wants to tell the world what it discovered, but doesn't want the real source of the information to be known. TAXII needs to support a method for that government to distribute the information while hiding the original information source.

This can be done by the use of NAT (Namespace Address Translation :) ). The governmental agency then can pipe its information through one or more other distribution groups, who can 'republish' the information under their own namespace. Each republisher would need to maintain a translation table of real GUID and translated GUID, as this would allow the government to receive sightings back to them without the other channel subscribers realising that the government organization was involved.

Trust that the information purporting to come from an organization actually came from that organization

A lot of the use cases above also hinge on the ability of TAXII to establish that information purporting to come from a namespace really did come from that namespace. We need to be able to unequivocally state that threat intel really did come from a particular source. This becomes extremely important when information may have traversed 3 or 4 different TAXII servers on its way from the producer to the consumer. Any in-between TAXII server may man-in-the-middle the connection, and may attempt to modify the contents of that object. TAXII needs to resist such attacks.

External visibility of restricted content

In many instances threat intelligence is restricted to a minimal set of recipients. At while it is possible to secure TAXII using encryption, TAXII needs to require it. When traffic is being sent across multiple hops, there is no potential guarantee that each hop has encrypted their link. TAXII should require encryption in line with current trends (just like HTTP/2 are contemplating).

Victim Notification

Sometimes a research/analysis organization will learn that another company has been compromised. Today, there is no standardized way for one company to contact another "out of the blue". This should be investigated as a possible TAXII use case.

Discovery

Let's make it easy to find content. A TAXII server should be queriable in such a way that it can disclose TAXII servers that it knows about. It should also be able to display feeds from those servers that it knows about. There should be a method for a TAXII server to register itself, and its feeds, with another TAXII server for discovery purposes. We should give a method for TAXII servers to also provide a name, title, description, and information regarding authentication when registering with a remote server. < I am sure I am missing features here, just want to get this in before I lose the thought >

Create a Group

Create a group on a TAXII Server and invite others

Create a Channel

Create a channel on a TAXII Server and invite others

You can’t perform that action at this time.