CTI TAXII Subcommittee

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. On 17 October 2015 at 01:57, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From my perspective - while I think that having QUERY for CTI is a fundamental and necessary use case - I think bundling it in with TAXII creates needless confusion. Not all use cases for TAXII care about QUERY. And not all use cases that care about QUERY, care about TAXII. QUERY also has a lot more implicit ties to the data model. TAXII does not need any of these. I feel that QUERY should be it's own separate API that may even follow a totally different paradigm. It should have it's own, seperate specification - and if needed, even have a different CTI subcommittee created for it. It's really an entirely different use case. Just because they were shoe-horned together in TAXII 1.X does not mean we can not fork it off now. - 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 "Davidson II, Mark S" ---2015/10/16 08:37:12 AM---Trey, One of our stated requirements for TAXII 2 is feature parity with TAXII 1.x [1]. To me, that m From: "Davidson II, Mark S" < mdavidson@mitre.org > To: Trey Darley < trey@soltra.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: " cti-taxii@lists.oasis-open.org " < cti-taxii@lists.oasis-open.org > Date: 2015/10/16 08:37 AM Subject: RE: [cti-taxii] Items in scope vs out of scope Sent by: < cti-taxii@lists.oasis-open.org > Trey, One of our stated requirements for TAXII 2 is feature parity with TAXII 1.x [1]. To me, that means query has not been scoped out. That said, there is still plenty of conversation to be had about query (e.g., what feature set constitutes 'feature parity' as well as the actual design). The graphic Bret shared was intended to convey that for any particular discussion there are four high level buckets of "scope" to consider. The graphic was not intended to be a complete list of TAXII 2 features - it only includes items that this SC have discussed so far. If you (or anyone) have ideas or requirements for query, please share them! Thank you. -Mark [1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements -----Original Message----- From: Trey Darley [ mailto:trey@soltra.com ] Sent: Friday, October 16, 2015 4:22 AM To: Jordan, Bret < bret.jordan@bluecoat.com >; Davidson II, Mark S < mdavidson@mitre.org > Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Items in scope vs out of scope On 15.10.2015 17:28:48, Jordan, Bret wrote: > > As we begin work on writing the specification for TAXII 2.0 I want > to make sure we are diligent about capturing your ideas, questions, > comments, and concerns. I also want to try and be very clear on > where things might fall in the scope discussion. By doing this I > believe we will remove confusion and allow us to focus on specific > scoping concerns that people might have. > > To this end I would like to propose that we document the decisions > we have already made in this SC and how they relate to scope in a > manner that looks something like the following graphic..... BTW, > this is an early rough draft with only the most basic information.. > Hey, Bret & Mark - Am I correct in my understanding that a query capability is currently considered out of scope for TAXII 2.0? -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com

[+1] To the concepts that (1) TAXII should focus on the secure transportation of "Packages" and (2) beyond the high level Class metadata describing such packages and their contents (i.e., this contains a STIX VX.x Package...), should be content agnostic. [+1] Query belongs in the context domain of the package class/methods that understand it's contents/structures. Patrick Maroney On Fri, Oct 16, 2015 at 9:22 PM -0700, "Terry MacDonald" < terry.macdonald@threatloop.com > wrote: 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. On 17 October 2015 at 01:57, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From my perspective - while I think that having QUERY for CTI is a fundamental and necessary use case - I think bundling it in with TAXII creates needless confusion. Not all use cases for TAXII care about QUERY. And not all use cases that care about QUERY, care about TAXII. QUERY also has a lot more implicit ties to the data model. TAXII does not need any of these. I feel that QUERY should be it's own separate API that may even follow a totally different paradigm. It should have it's own, seperate specification - and if needed, even have a different CTI subcommittee created for it. It's really an entirely different use case. Just because they were shoe-horned together in TAXII 1.X does not mean we can not fork it off now. - 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 "Davidson II, Mark S" ---2015/10/16 08:37:12 AM---Trey, One of our stated requirements for TAXII 2 is feature parity with TAXII 1.x [1]. To me, that m From: "Davidson II, Mark S" < mdavidson@mitre.org > To: Trey Darley < trey@soltra.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: " cti-taxii@lists.oasis-open.org " < cti-taxii@lists.oasis-open.org > Date: 2015/10/16 08:37 AM Subject: RE: [cti-taxii] Items in scope vs out of scope Sent by: < cti-taxii@lists.oasis-open.org > Trey, One of our stated requirements for TAXII 2 is feature parity with TAXII 1.x [1]. To me, that means query has not been scoped out. That said, there is still plenty of conversation to be had about query (e.g., what feature set constitutes 'feature parity' as well as the actual design). The graphic Bret shared was intended to convey that for any particular discussion there are four high level buckets of "scope" to consider. The graphic was not intended to be a complete list of TAXII 2 features - it only includes items that this SC have discussed so far. If you (or anyone) have ideas or requirements for query, please share them! Thank you. -Mark [1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements -----Original Message----- From: Trey Darley [ mailto:trey@soltra.com ] Sent: Friday, October 16, 2015 4:22 AM To: Jordan, Bret < bret.jordan@bluecoat.com >; Davidson II, Mark S < mdavidson@mitre.org > Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Items in scope vs out of scope On 15.10.2015 17:28:48, Jordan, Bret wrote: > > As we begin work on writing the specification for TAXII 2.0 I want > to make sure we are diligent about capturing your ideas, questions, > comments, and concerns. I also want to try and be very clear on > where things might fall in the scope discussion. By doing this I > believe we will remove confusion and allow us to focus on specific > scoping concerns that people might have. > > To this end I would like to propose that we document the decisions > we have already made in this SC and how they relate to scope in a > manner that looks something like the following graphic..... BTW, > this is an early rough draft with only the most basic information.. > Hey, Bret & Mark - Am I correct in my understanding that a query capability is currently considered out of scope for TAXII 2.0? -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com

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.

I disagree. STIX is an information format - TAXII is the service that (may) deliver(s) it. A Query Service should be part of the transport, not the data format. It's the natural place for it to exist. Adding a Query Service to STIX wouldn't be STIX, it would be a service attached to STIX, which is what TAXII is. Cheers! ~r ron.williams@us.ibm.com stsm, ibm master inventor chief architect, infrastructure protection divisional idt lead ibm mobile +1.512.633.7711 ofc +1.720.349.2236 ??·???? ??????????? IBM?? "It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb "Jason Keirstead" ---10/19/2015 13:17:47---Agree 100% with your vision Terry and I think you expressed the argument better than I. From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> 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" <cti-taxii@lists.oasis-open.org> Date: 10/19/2015 13:17 Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query Sent by: <cti-taxii@lists.oasis-open.org> 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.

Hi Ron; I think where we're deviating here is this statement: "... it would be a service attached to STIX, which is what TAXII is. " We're trying very hard to not bind TAXII to STIX, hence this discussion about splitting QUERY off as a separate work product. Having QUERY as part of TAXII core would imply a lot of things - not the least of which is that all producers of CTI also must act as a CTI repository, which is simply not the case. That's why we are trying to be very deliberate here and separate QUERY from the core of TAXII, which is the live or near-live transmission of intelligence. - 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 "Ron Williams" ---2015/10/19 01:48:55 PM---I disagree. STIX is an information format - TAXII is the service that (may) deliver(s) it. A Query S From: "Ron Williams" <Ron.Williams@us.ibm.com> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: Terry MacDonald <terry.macdonald@threatloop.com>, "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/19 01:48 PM Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query Sent by: <cti-taxii@lists.oasis-open.org> I disagree. STIX is an information format - TAXII is the service that (may) deliver(s) it. A Query Service should be part of the transport, not the data format. It's the natural place for it to exist. Adding a Query Service to STIX wouldn't be STIX, it would be a service attached to STIX, which is what TAXII is. Cheers! ~r ron.williams@us.ibm.com stsm, ibm master inventor chief architect, infrastructure protection divisional idt lead ibm mobile +1.512.633.7711 ofc +1.720.349.2236 ??·???? ??????????? IBM?? "It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb "Jason Keirstead" ---10/19/2015 13:17:47---Agree 100% with your vision Terry and I think you expressed the argument better than I. From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> 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" <cti-taxii@lists.oasis-open.org> Date: 10/19/2015 13:17 Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query Sent by: <cti-taxii@lists.oasis-open.org> 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.