Re: [cti-stix] RE: STIX Sightings

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

I feel like the use case around RFI is not clearly fleshed out.

What parties and systems would be issuing RFI requests and under what circumstances?
What parties and systems would be responding to said requests?

Only once those two things are well documented and understood by all can we understand how to best service such a request.

As an example of why this is important... I believe only a tiny fraction of potential TAXII client systems would ever have an ability to respond to historical RFI requests... Most would not. So maybe this RFI capability should be limited to only TAXII servers who implement a "repository" specification.

Sent from IBM Verse

Aharon Chernin --- Re: [cti-stix] RE: STIX Sightings ---

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

---

As a community we need to figure out: are RFIs handled through TAXII query or are they handled via something like a STIX Request Package as Terry proposes. I do tend to lean towards TAXII query, but if the community likes the STIX Request Pack approach better then we should depreciate the functionality from TAXII Query. I would like to avoid having two different ways to do the same thing. Aharon On 10/30/15, 4:55 AM, "Trey Darley" <trey@soltra.com> wrote: >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