Re: [cti-taxii] TAXII Query / Search

On Nov 19, 2018, 2:26 PM -0500, Bret Jordan <Bret_Jordan@symantec.com>, wrote:

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

cti-taxii message