As a bit of background, in TAXII 1.1, query was a separate specification [1]. The key reason for the separation was that query was viewed as less mature than
the rest of TAXII and a separate specification was a way to encapsulate query functionality. This way, query could be versioned separately from the rest of TAXII as it matured. In practice this separate revision has not happened. My reason for bringing this
up is to identify precedent for query being its own specification, even if the choice was made for different reasons than are currently being discussed.
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.
Thank you.
-Mark
[1] https://taxiiproject.github.io/releases/1.1/
From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]
Sent: Monday, October 19, 2015 7:14 AM
To: Terry MacDonald <terry.macdonald@threatloop.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; Trey Darley <trey@soltra.com>; Jordan, Bret <bret.jordan@bluecoat.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query
Agree 100% with your vision Terry and I think you expressed the argument better than I.
Now my question is, how to make it a reality :) IE, if STIX is responsible for answering QUERY messages, how does this work...
Presumably, if TAXII 2.0 was a REST service, then you would want QUERY 2.0 to be a REST service as well so that servers who have TAXII can also run a QUERY endpoint on the same port.
So that is feasible, but the question is, how do we come up with the specification for this service. Is this something for the STIX SC? Or a "QUERY" SC?
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security |
www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
Terry
MacDonald ---2015/10/17 01:22:25 AM---Hi All, Just splitting this out into its own thread so we can all keep track :)
From: Terry MacDonald <terry.macdonald@threatloop.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Davidson II, Mark S" <mdavidson@mitre.org>, Trey Darley <trey@soltra.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>,
"cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/10/17 01:22 AM
Subject: [cti-taxii] The need (or no need) for TAXII to support Query
Sent by: <cti-taxii@lists.oasis-open.org>
Hi All,
Just splitting this out into its own thread so we can all keep track :)
I half agree with Jason :). I think Query is outside of the scope of TAXII, but I also think it is the responsbility of each carried protocol to provide its own query and response functionality if it requires it.
To me TAXII has the express purpose of enabling the sharing of CTI data (over a channel). To me that means that TAXII is only worried about:
- ensuring everyone allowed to see the CTI data channel sees it
- allowing people to request access to the CTI data channel
- allowing channel owners to allow access to the CTI data channel
TAXII should effectively treat the information carried within TAXII as a 'black box' from the TAXII perspective. As an example, if a TAXII channel is carrying STIX data, then it should be the responsibility of STIX to ask queries
for STIX data. Similarly, if in the future TAXII carries VERIS classification data, then it should be the responsibility of VERIS to ask queries for VERIS data. TAXII should just ensure that the data gets to where it should go, and that only those who are
allowed to see it, receive it. (And that it is marked to contain either STIX or VERIS data so the receiving TAXII process knows which process to hand the carried data to.
Loosely coupling TAXII from the data it carries gives us future flexibility for what TAXII can carry. Tightly coupling TAXII by enforcing support for STIX querying restricts this flexibility, and ensures that when new version
of STIX is released we will need to release a new version of TAXII query to support it. And then restricts the ability for us to add new protocols to be carried by TAXII (e.g. VERIS) as new TAXII query releases would be required there too.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My opinions do not necessarily reflect those of Threatloop.com.