From the discussion so far, I’ve heard different viewpoints on:
·
What TAXII Query should actually look like
·
Where/how TAXII Query and TAXII Channels should be defined (e.g., same spec, different specs, different SCs)
I think having a rough design for TAXII Query would help the group reach a shared understanding on the above topics. To that end, Bret and I (we spoke offline)
would like to propose that we build a strawman TAXII Query. The goal of the exercise would be to come up with a shared understanding of how TAXII Query fits into our work and what dependencies it has; the ability to use the strawman design as a foundation
for a future TAXII Query would be a secondary benefit and not necessarily a requirement.
Trey, I’d like to take you up on your offer to share your REST API as a strawman; it would be a great start to the conversation.
Thank you.
-Mark
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Tuesday, October 20, 2015 10:55 AM
To: Trey Darley <trey@SOLTRA.COM>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Terry MacDonald <terry.macdonald@threatloop.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query
Thanks for the insight in to what you all need. I think your view is very similar to what I would like to see. Structurally I am just calling it something different...
<me personally, not as co-chair>
I would like to see three work products be delivered out of the TAXII SC.
1) TAXII Specification for transporting CTI
Extension Points for other authentication system
And possible a few other minor things here and there
2) A Query Specification that plugs in to the TAXII REST API
3) Build a getting started guide to add some context around how you might build a storage repository for TAXII. Most of this would be implementation or
deployment specific and not specification related, but I think it would be good to help people understand from those of us that think about TAXII all day long, how we envision it working.
Query would be Optional to implement. However, if you do implement it, it would look and feel like it belongs, not like it was patched in as a secondary
after thought.
</off soap box>
What something like this be acceptable to everyone? Please push back.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
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
|