RE: [cti-taxii] TAXII Use Cases

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

- One thing I would add to the drawing - Organization 2 also talking to the Threat Exchange.

- RE Storing - One "why" I could give for storage is for resiliency. Without storage of messages on the TAXIi server, if I ever do not have a connection to the server when an important sighting or indicator is shared, I will never receive that message. IE, one can not assume that all consumers are "live".

- RE Querying - The "why" here hinges on who we would rather be the logical owner of the database of record of threat data, the server or the client. If you want to have a centralized database of record, then the client should be able to query that database. If there is no querying in the protocol and the sever in fact has no database of record (and is simply assumed to be a broker), then client systems will have to build up a copy of the database of record and query it locally instead. In a way this decision is analogous to if you want to do distributed or centralized source control.


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Davidson II, Mark S" ---2015/07/20 02:26:03 PM---Jason, Thank you for posting this. I'd like to highlight one of your paragraphs, as I see it as prob

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: Ron Williams <Ron.Williams@us.ibm.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/07/20 02:26 PM
Subject: RE: [cti-taxii] TAXII Use Cases

---

Jason,
 
Thank you for posting this. I’d like to highlight one of your paragraphs, as I see it as probably the most important perspective this group should have:

> When considering development of TAXII 2.0, I feel like this is an opportunity to do things well, and in order to do that, we need to get back to root principals. What are the things TAXII wants to do, what is it trying to solve? Only when your end goal is understood in a clear and concise way can one hope to create a standard that enables that goal.

With that, I’ll hit on some other points from the thread.
 
# Architecture
This is a bit of a tangent, and forgive the ugliness, but I’ve attempted to draw the architecture Jason described (perhaps with my own un-noticed biases). I used PlantUML[1] (Note: SourceForge is currently down), and I’ve attached my source file in case anyone is interested. I find PlantUML to be pretty useful for quickly whiteboarding ideas.
 
Notional Architecture:

# Use Cases
Focusing on back on use cases (the subject of this thread), I think what we have is a good starting point, and eventually we’ll need to increase the level of abstraction for the use cases offered so far. Fortunately, there is a very easy process for raising a use-case’s level of abstraction: Ask Why. Ask why until the use case is sufficiently high level.
I’ll pick on the use case of: “storing messages and allowing querying”. I personally – with the information provided – do not have enough information to determine whether I think message storage/query is something that TAXII 2.0 should support. So I’ll ask why. Why do we need storage and query? I’ll note that this is not Bret’s question alone to answer – anyone who has any answer should feel compelled to provide it. Multiple answers will provide a greater selection of use cases and perspectives.
                I’ll also note that this message is meant to encourage contribution of all use cases, no matter how high or low level. It’s an easy and useful process to turn a low-level use case into a high-level use case. It’s easy because we just ask “why?”; it’s useful because we might get unanticipated answers that help make TAXII better (e.g., I won’t know what you’re thinking if you don’t say it). More use cases are always better than less use cases, because more use cases gives you more to work with. So please do not hesitate to offer your thoughts on use cases.
 
As for my own contribution of use cases, I’ll offer these:

· Send an Indicator
· Send a Sighting

I think many of you who have read this far will be asking: “Why?”
 
Thank you.
-Mark
 
[1] http://plantuml.sourceforge.net/

From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Friday, July 17, 2015 5:54 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Ron Williams <Ron.Williams@us.ibm.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] TAXII Use Cases

Great ideas, Jason thanks for posting. Everything should be on the table at this point. Meaning I do not see any reason why TAXII could not have TLP information in it. And yes TAXII 2.0 needs authentication!!!!

Some use case ideas at an even higher level will be.

1) storing messages and allowing query

2) send on a channel and forget. Meaning if you are listening you get it, if not then you miss it

Bret

Sent from my Commodore 64

On Jul 17, 2015, at 12:01 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
I am not referring to services, but use cases

Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified?

Yep that is what I am asking specifically. (4) and (5) can not be properly handled with TAXII 1.X. I am asking to brainstorm to try to solve these problems under TAXII 2.0, and asiking if this can even be solved soley in the TAXII realm (I am not sure it can since STIX currently handles the TLP).

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>Ron Williams---2015/07/17 02:30:54 PM---So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inb

From: Ron Williams/Austin/IBM
To: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Cc: cti-taxii@lists.oasis-open.org
Date: 2015/07/17 02:30 PM
Subject: Re: [cti-taxii] TAXII Use Cases


---




So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inbox.

For your case 5, isn't this the Inbox Protocol (combined with CMS and CIS as approrpriate)? I don't see TAXII as unable to address 1-5, but rather that the currently deployed services that use the protocol don't yet implement these use cases. Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified? Or is a matter than no one has deployed the services on TAXII that represent them?

Cheers!

~r

ron.williams@us.ibm.com | stsm, ibm master inventor | chief architect, infrastructure protection | divisional idt lead | ibm | mobile +1.512.633.7711 | ofc +1.720.349.2236
"It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb



<graycol.gif>"Jason Keirstead" ---07/17/2015 11:56:11---Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should sha

From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: cti-taxii@lists.oasis-open.org
Date: 07/17/2015 11:56
Subject: [cti-taxii] TAXII Use Cases
Sent by: <cti-taxii@lists.oasis-open.org>


---





Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should share this with the whole group.

When considering development of TAXII 2.0, I feel like this is an opportunity to do things well, and in order to do that, we need to get back to root principals. What are the things TAXII wants to do, what is it trying to solve? Only when your end goal is understood in a clear and concise way can one hope to create a standard that enables that goal.

The way I see the landscape evolving, there are five main classes of TAXII usage. Some products may support multiple classes, some may only support one.. but these are the five main interaction paradigms at play.

1) TAXII clients who act as producers of threat information. One example of this may be a layer 7 firewall that has a rule that publishes responses via TAXII to another product, or an analyst manually submitting a research product via a tool.

2) TAXII clients who act as consumers of threat information. One example of this may, again, be a layer 7 firewall that consumes threat information (observables) and uses the information to create rules, or an analyst reading a threat feed either manually or via a tool.

3) TAXII servers who act as message brokers within an organization (an enterprise/governmental entity/user group). These servers federate the information between the (1) and the (2) TAXII clients within the organization.

4) TAXII servers who act as message brokers among other TAXII servers (an example of this would be FS-ISAC). This is the point where data authorization starts becoming important. For example, say I publish a package to my local TAXII server with several components, some of which I want to be available to be brokered to everyone in the group, and some of which I only want to be available to select entities in the group with whom I have a trust relationship, or those with specific rights. Obviously, this has to tie into authorization.

5) TAXII servers who act as public or subscription based threat exchanges that allow publish and subscription to feeds. This is not the same use-case as (4) because of the fact that it is a public threat exchange, anyone may be contributing - thus, authentication and authorization to data is paramount. For example, say I create an account on a public exchange claiming to represent Company A or Entity A - how can that exchange validate that I am allowed to speak with authority for that company? Furthermore

Traditionally, I feel like TAXII (and STIX as well) have been focused on 1-3, while neglecting 4 and 5. The problem is, 4 and 5 are what is going to get STIX wide adoption.

Once you get into (4) and (5) there is a whole set of use cases that TAXII 1.X has not tacked, that I have brought up on the MITRE lists many times... issues with authentication, authorization, validation of chains of authority, public registries, etc etc... the list goes on.

I am not sure which CTI group this effort belongs in but TAXII feels like it may be the best fit... although it also ties into the TLP mechanism in STIX, which needs re-thought to deal with these issues.

I am wondering what the thoughts are in the group around these issues of not just authentication, but also authorization and trust chains... do these belong in a TAXII 2.0, and if not, how can we enable these above use cases.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

[attachment "notional_architecture.txt" deleted by Jason Keirstead/CanEast/IBM]