cti-taxii — archive

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

From: Mark Davidson <[email protected]>
To: [email protected]
Date: Tue, 20 Oct 2015 19:53:00 -0000

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:[email protected]] Sent: Tuesday, October 20, 2015 10:55 AM To: Trey Darley <[email protected]> Cc: Davidson II, Mark S <[email protected]>; Jason Keirstead <[email protected]>; Terry MacDonald <[email protected]>; [email protected] 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 HTTPS REST HTTP Basic + JWT 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 HTTPS REST 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. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems 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 Oct 20, 2015, at 02:53, Trey Darley < [email protected] > wrote: 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