cti-taxii message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-taxii] TAXII Query / Search
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Mon, 19 Nov 2018 16:06:11 -0400
Hi Brett - Terry and I have an alternative
proposal we've been asking the TC to have a look at here
https://docs.google.com/document/d/1Cy_9Bh5tKEkDHGg2iv5c3AwriqVr7ygbKXWOv4-uHxs/edit#heading=h.1jcqb6vc5y7z
As we lay out in the document, there
are a number of issues TAXII has with query, and I think the proposal you
have below is insufficient to solve the use cases we have in Github:
We first started working on this last
Christmas - so it's been almost an entire year. We've been struggling to
get feedback on the document and would like the TC to comment on it. It
is in my opinion a very simple proposal - yet it allows query to be extensible
for many future use cases.
We need to avoid endpoint pollution
as one tries to bolt-on new endpoints and arguments for every kind of query
parameter under the sun without any plan for the future use cases we have
to meet.
Issue
15 - As a User, I want to traverse the STIX graph over TAXII in an efficient
manner...
Issue
7 - Need ability to request related objects in one request to a distance
of 1(?)
Issue
5 - Add support to get embedded objects in a single request, dereference...
Issue
6 - Add ability to find all objects related to a particular STIX object
ID
Issue
4 - TAXII Observed Data Query
Also, I think "the biggest element
holding people back" is very much open to interpretation and what
persona you fill. From the perspective of most any SOAR-based security
tool integrating with a TAXII server, the biggest element holding me back
is ability to find indicators that match an observation, or find observation
that match an indicator.
Finding out who is related to a STIX
object is very much a TIP-centric use case (although I will add that that
use case is also addressed in our above proposal as well).
My point is that we should not be trying
to come out with a lot of piecemeal-endpoints without thinking of the bigger
picture of query.
-
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
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
"cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Date:
11/19/2018 03:26 PM
Subject:
[cti-taxii]
TAXII Query / Search
Sent by:
<cti-taxii@lists.oasis-open.org>
All,
Over the past year I have heard from several
people that they are unable to implement TAXII because there is no way
to search for relationships. Yes, there are lots of other things that people
would like to do with a query request, but the ability to search for a
relationship seems to be the single biggest missing element holding people
back from implementing TAXII.
I have talked with Drew and Gary about
how we could solve this in the very short term and would like to propose
the following solution to the TC. If the TC agrees with this, Drew and
I can add this to Working Draft 05 in the next week and submit Working
Draft 05 to the TC for Review and CSD ballot the first of December.
Proposal
1) We create an endpoint called:
<api-root>/collections/<id>/relationships/related-to/<stix-id>/
This endpoint would return any SROs where
the source_ref or target_ref matched the supplied STIX ID. This would be
a very simple database query, and would not require a lot of computation
work. This endpoint would be mandatory to implement for all TAXII
Servers as defined in the conformance section.
2) We add an optional URL parameter for
the relationships endpoint called:
?deref=true
This optional URL parameter would tell the server to automatically send
the objects that are referenced in the SROs that are being returned. From
a conformance standpoint, this URL parameter would be optional to implement.
If a client makes a request with that URL
parameter and the server has not implemented it, the server would respond
with an HTTP 501 Not Implemented error code and a TAXII error message that
says the URL parameter is not implemented.
From a database performance standpoint,
this URL parameter would require that the server perform multiple database
queries for each request and would require the server to do some book keeping
to ensure that it does not send the same object multiple times. However,
this feature would eliminate the overhead of parsing multiple RESTful requests
from the client as it comes back and asks for each of the objects one at
a time.
Conclusion
We have some support for doing this already
as this would be easy to implement in the specification and in code, and
would solve a major blocker that has been identified. I would be curious
to know if anyone else would support this or be against this. This
does not mean that we will not look at a more elaborate pattern based /
property based query solution in the future.
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]