Re: [cti-taxii] TAXII Architecture

[Mark Davidson <mdavidson@soltra.com>]

I learned from a conversation offline (and seen reinforced in this conversation) that the term repository might have a connotation about defining/requiring a particular backend technology. So far, the term repository has been intended to represent an interface into a repository (e.g., defining URLs, methods, etc) but not define how that content is stored or retrieved. If this is the case generally – that the term repository has a connotation that makes understanding more difficult – I think we can explore other terms (repository interface?).

TAXII should be easy to understand, and this starts with the terminology that we use to describe our high level concepts.

Thank you.

-Mark

From: <cti-taxii@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, December 16, 2015 at 11:28 AM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] TAXII Architecture

This is highlighting why I think we should be focusing on the protocol and not the implementation. Yes, the implementation will inform the protocol, but the point of focusing on what needs to be traded, instead of how it gets stored, enables people to innovate in their implementations and come up with cool and novel things to do.

Case in point: the purpose of HTTP 0.9 was to transfer academic papers with references from here to there. So, a protocol that enables you to address a paper (URL), suck it down (HTTP), and even have that paper point to other papers (embedded URL’s in HTML) that could be sucked down with the same addressing (URL) and protocol (HTTP) was great, but by not focusing on how those documents got stored, manipulated, or retrieved, enabled dynamic web pages, SOAP, REST, and a whole host of things not envisioned in 1994.

On Dec 16, 2015, at 11:17 AM, Mark Davidson <mdavidson@soltra.com> wrote:

I have received the following comment from a member of the cti-taxii list who has requested to remain anonymous:

Potential Use Case 1 for a hypothetical [Govt] organization: An organization is under some kind of regulatory, legal, compliance constraints such that they cannot "store" the information - they can merely deliver it.   In this situation, they may"cache" the information for some period of time if the consumers are not currently listening but it's more like the post-office vacation-hold than query/storage.    Result: TAXII does pub/sub only.

Potential Use Case 2 for some hypothetical Govt organization:  Some information is classified with all kinds of different need-to-know caveats in the same STIX document.   The decision on which fields are available to a particular consumer is on an entity-by-entity basis.   This is impossible to implement in a pub/sub model because you might have -say- 10 types of attributes of a person in terms of their need-to-know.   A given document can have fields that have require between 1-10 of those need-to-knows.  (that's 10! combinations or something factorial - I forget the equation)  So you can't create a 10! different feeds for each of those 10! need-to-knows.    Result: TAXII does query only and forms the response based on the need-to-know attributes of the entity making the query.

I'm going to argue that the TAXII tool that is optimized for Use Case 1 is 100% designed differently than one optimized for Use Case 2.  If you have to do both, I posit that's a waste of time and you may compromise and end up with something that isn't optimized well for either one of these.

I'm sorry that I'm a late arrival to this discussion.  But are you going to talk about the potential for a TAXII implementation that is more focused on real-time control, say within an organization, where some real time intelligent controller uses TAXII to send just STIX COA primitives (i.e. block-this-IP-address) to a particular router.    That's not really pub/sub but more a directed control communication.   Or is this out of scope for TAXII?

Thank you.

-Mark