Re: [cti-taxii] The need (or no need) for TAXII to support Query

[Trey Darley <trey@soltra.com>]

On 19.10.2015 12:43:14, Davidson II, Mark S wrote:
> 
> One of the primary challenges for TAXII query was the inability to
> tightly bind the query model to a specific version of STIX. This
> resulted in the Targeting Expression concept, which is a way to bind
> a query to a specific version of STIX. Successful implementation of
> the Targeting Expression effectively requires implementers to have a
> high degree of communication and coordination - something a spec
> (IMO) should decrease. There are successful implementations out
> there, and the ones I know about have a shared characteristic of
> central planning. While this is manageable, I think it is an area
> that can be improved for the next iteration of query, whatever form
> it takes.
> 

(My apologies in advance, this is going to be a rather long mail.)

Mark notes, "There are successful implementations out there". I'd be
curious to see them, as to I have yet to bump into an implementation
of TAXII Query.

Early on, Soltra identified three basic use cases for TAXII Query:

  0) Have you seen this thing?
  1) Give me everything you've got that's related to this thing.
  2) Give me everything you've got that's of type Foo.

Our end goal is to make integrating Edge with other systems (ie,
network/endpoint blackboxen that don't speak STIX/TAXII) dead simple.
After all, what's the point of having a pile of CTI if you can't
easily leverage it to solve real world problems!?

We spent over a year looking at the TAXII Query spec, scratching our
heads, and having long conversations with MITRE. In the end, to be
able to address the three simplistic use cases described above would
have required us to define a proprietary Soltra Query spec. This
seemed like overkill. Faced with the necessity of implementing a
proprietary solution, we decided to go REST (since everybody and their
sister know how to interact with REST.)

We're well on our way to releasing a version of Edge that includes
this REST query API. (No secret, it's been discussed at length in
public fora.)

I appreciate the desire to make TAXII 2.0 content-agnostic. It would
be nice if TAXII 2.0 could transport OpenIOC, VERIS, BitTorrent
tracker files, and the kitchen sink. *However*, TAXII 2.0 is an OASIS
CTI standard and as such owes its *primary* allegiance to supporting
the needs of its sister OASIS CTI specs.

We at Soltra were loathe to implement a proprietary query solution but
felt there was no better option. Our intention has always been to work
within OASIS to ensure that TAXII 2.0 Query supported the basic use
cases mentioned above and once TAXII 2.0 was released, to deprecate
our proprietary REST API in favor of TAXII 2.0 Query.

If Query is deemed out-of-scope for TAXII 2.0, I can foresee two
possibilities:

  0) Some kind of top-level STIX/CybOX Query construct will be
     promulgated.
  1) Vendors will implement proprietary REST query APIs.

Both of the possibilities strike me as utterly absurd outcomes. I
think going REST for TAXII 2.0 is brilliant! Let's include a query API
in the spec. I take Ron's point that not all CTI producers will also
necessarily act as repositories *but* a great many of them will. So
let's make TAXII 2.0 Query *optional* but at least define what it
should look like, if a vendor *chooses* to support it.

We'd be happy to share what our REST query API definition looks like
as a strawman.

-- 
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
--
"It is always something." --RFC 1925

Attachment: signature.asc
Description: PGP signature