RE: [cti-stix] RE: STIX Sightings

["Davidson II, Mark S" <mdavidson@mitre.org>]

Copying cti-taxii on the reply.

The current state of the TAXII 2 conversation is that essentially this:
* There will be a channel-based API for broadcasting messages
* There will be TAXII messages and workflows, but we haven’t defined any yet
* There are certain cases (e.g., get by ID) that seem to fit much better into a straight-up request/response API vs. the channel-based concept

The TAXII SC is currently working through what the difference really is between the Channel API and the Query API, and what that means for the TAXII SC (really, CTI TC) work products - do we need both types of API? If so, do they belong in different specs?

I personally think that some form of a "STIX Repository API" is worth considering. I call it that because the URL structure would be intrinsically linked to STIX (e.g., GET /indicators/<indicator-id>/ ). I personally don't care which SC the work is done in, as long as we are doing valuable work that makes sense and advances STIX/TAXII. The notion of a "STIX Repo API" probably sits right on the STIX/TAXII scope boundary for most people.

> The tl;dr is to add an optional 'broadcast' parameter to TAXII query.
> If not specified, assume that a query is targeting just the local CTI
> repository. If the flag is specified, the CTI repository receiving the
> query acts as a proxy, forwarding the incoming query to all the hosts
> implied by the specified trustgroup(s), collecting the query results,
> and passing them back to the client.

Alternatively (and I'm not sure how well this would actually work, I'm just putting it out there for discussion), if you had a STIX Repo API and a TAXII Channel API, the client would know whether the request was "direct" or "broadcast" based on which URL it was asking.

**I think they key consideration here is whether a TAXII Server is a repository, a message broker, or both** - partly, this is what's under discussion in the TAXII SC. TAXII 1.x sort-of folded both concepts into the same spec. The TAXII 2 conversations started out by focusing on the message broker aspect and found that certain repository functions (e.g., get by ID) are somewhat awkward to implement over a broker (e.g., you need to broadcast a request and hope that a broker client is subscribed, and you need to be able to handle 0-* responses to your request). This has led to the recent discussion on Query API that Trey mentioned.

Thank you.
-Mark

-----Original Message-----
From: Trey Darley [mailto:trey@soltra.com] 
Sent: Friday, October 30, 2015 4:56 AM
To: Terry MacDonald <terry@soltra.com>
Cc: Barnum, Sean D. <sbarnum@mitre.org>; Patrick Maroney <Pmaroney@Specere.org>; Aharon Chernin <achernin@soltra.com>; Davidson II, Mark S <mdavidson@mitre.org>; Joep Gommers <joep@eclecticiq.com>; Jonathan Bush (DTCC) <jbush@dtcc.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] RE: STIX Sightings

On 29.10.2015 21:45:21, Terry MacDonald wrote:
> 
> PROBLEM:
> 
> There is no real mechanism within STIX for a consumer of STIX data
> to ask a question from the rest of the threat sharing community that
> they are part of. This functionality is required if we are going to
> get good multi-directional threat intelligence sharing happening.
> 

Wow, this is good stuff, Terry! I hadn't fully thought through the
notion of a broadcast query. Good on ya, man!

> 
> This is different from the normal 'broadcast' style STIX message,
> where the message is just sent to all parties and no replies are
> expected. With STIX request/response there is a direct
> question/answer relationship required.
> 
> Please note this request/response is also different to TAXII Query,
> as the question is being asked to all members of the channel, rather
> than just the single TAXII server you are locally connecting to
> (which is IMHO more where TAXII Query fits in).
> 

I'm biased, since I've been working on the notional query spec for
TAXII 2.0, but I think we can solve this via TAXII REST query instead
of creating two new top-level STIX objects. I've written up my
proposal for query scoping here [0].

The tl;dr is to add an optional 'broadcast' parameter to TAXII query.
If not specified, assume that a query is targeting just the local CTI
repository. If the flag is specified, the CTI repository receiving the
query acts as a proxy, forwarding the incoming query to all the hosts
implied by the specified trustgroup(s), collecting the query results,
and passing them back to the client.

[0]: https://taxiiproject.github.io/taxii2/notional-query-api/#query-scoping

-- 
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton