Re: [cti-taxii] TAXII Query / Search

[Sean Barnum <sean.barnum@FireEye.com>]

We believe that a full query solution will be needed for TAXII to meet its full potential but recognize that this will require considerably more discussion, design, experimentation and consensus and is not something that will be ready tomorrow.

 

We agree that there is an immediate need for relationship querying and support this proposal as a way to get us past the current blocker and as an interim step in right direction.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Monday, November 19, 2018 at 2:27 PM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: [cti-taxii] TAXII Query / Search

 

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

 

 

 

 

 

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.