cti-taxii message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Alternate Query Proposal Walk Through February 19th
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: cti-taxii@lists.oasis-open.org
- Date: Fri, 8 Feb 2019 09:30:40 -0400
I would like to be given the opportunity
to walk the TAXII SC through the alternative Query proposal that Terry
MacDonald and I created over 12 months ago
This proposal is located here - https://docs.google.com/document/d/1Cy_9Bh5tKEkDHGg2iv5c3AwriqVr7ygbKXWOv4-uHxs/edit#heading=h.1jcqb6vc5y7z
We have floated this proposal several
times to the SC - yet, there has never really been any debate, discussion,
or any significant comments on the document or with either of us, while
others have created these alternative proposals. My understanding is this
proposal may have been presented very briefly at the F2F, however no one
involved in the creation of it was present to defend it.
Most of the arguments I hear people
give against the proposal, I believe are based on false understanding of
how it works. Which is why we would like to be given the opportunity to
defend it.
I would like to plan to present this
to the TC on the working call on February 19th.
The benefits of this proposal over the
current relationship one:
- Ease of implementation. There
is a lot of misinformation about how hard this would be to implement. Because
query types are optional for implementations, it is actually extremely
simple to implement, much simpler than the current proposal is. It is also
simple to add query types to your software in the future.
- Interoperability and Optionality.
No implementor is required to implement any specific type of query,
however code implementations can 100% interoperate, due to trivial discoverability
of the types of supported types of queries
- Combinations. You can combine supported
query types to get what you want. I can ask for indicators that match
an observable *and* combine this with a request for relationships
- Modularity. We can add other types
of queries, without creating "endpoint hell". Vendors can
even make their own query types using STIX SEP process, and have them interact
with other query types in a 100% interoperable fashion.
- Sets you up for asynchronous queries.
STIX queries against data lakes of hundreds of TB can take some time to
fulfil. To expect one to be able to always fulfill a TAXII query in a synchronous
REST endpoint in all scenarios, is not realistic. In this implementation,
because the query resource is POSTed to the endpoint, it allows results
to be fulfilled asynchronously via an alternate channel (ie, TAXII channels).
Once TAXII channels exist, this will be extremely useful. However, even
right now, software could still use existing technologies like OpenDXL
to make this feature useful.
-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]