I would assert that finding who is related to X in a graph is about the most fundamental use case for CTI which TAXII is intended to support. This basic capability would support
numerous more specific use cases.
finding observables related to indicators and/or vice-versa is also a perfectly valid use case but a more specialized one limited to a specific subset of use cases within CTI.
We need to support both of these use cases eventually.
The challenge/decision that currently lays before us is that solving the second one is far more complex than solving the first one and we do not currently have a consensus solution. We have a well thought out proposal that may end up eventually
serving as a solution but it appears the consensus of the TC is that it still has multiple uncertainties and will need considerably more discussion, experimentation and consideration before achieving consensus that it is the best solution without significant
risk that it would need to be substantially changed or refactored in the future.
The proposal to solve the second use case (Option 1), due to its complexity and nascency, is far more likely to be broken as you call it than the very simple solution for the first use case (Option 2).
I would disagree with your characterization of Option 2 as broken or being extremely likely will have to deprecate it .
Is it incomplete for the full scope of querying use cases? Yes, certainly.
Is there anything wrong or broken with it? No.
Does it provide significant value immediately with low risk? Yes.
Could it be deprecated in the future IF desired with very minimal impact to anything around it? Yes.
Could it also be left in place to serve its more limited use case for implementations wishing to serve specifically that use case? Yes.
To me, the value tradeoff between the two options is relatively clear.
Option 2, while not fully covering all query use cases is extremely simple to define and implement, provides significant requisite value and has low risk of breaking anything or preventing future evolution and extension.
Option 1, MAY provide a broader solution to more of the querying use cases but does not have consensus and will require levels of discussion and experimentation that make it infeasible for 2.1.
I think it is more important to make 2.1 an MVP than it is to leave 2.1 as inadequate while trying to solve the full problem space in one huge leap.
That is my opinion.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E:
sean.barnum@fireeye.com From: <
cti@lists.oasis-open.org> on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com>
Date: Monday, February 4, 2019 at 9:32 AM
To: Chris Larsen <
Chris_Larsen@symantec.com>
Cc: Bret Jordan <
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] Re: Relationship queries in TAXII
The problem with Option 2 is, we already know it is extremely likely will have to deprecate it because it doesn't take into account extremely important use cases revolving around
combining filters (find me things related to X, that match indicator Y).
I am not comfortable proceeding with things we know are partially broken and/or likely incompatible with future scenarios. We have done this too many times with STIX and TAXII 2.X, look at the churn
it has created.
* I would rather do nothing than proceed with broken things.
* For ourselves at least, finding observables related to indicators and/or vice-versa is actually far more important than finding who is related to X in a graph. The former is a use case that extends
to almost every product in the cybersecurity industry, the later is a use case that is mainly relevant to TIPs and those trying to curate higher level intelligence.
-
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: Chris Larsen <
Chris_Larsen@symantec.com>
To: Bret Jordan <
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Date: 02/01/2019 05:44 PM
Subject: [cti] Re: Relationship queries in TAXII
Sent by: <
cti@lists.oasis-open.org>
Modern/agile software development theory argues in favor of option #2.
There is much virtue in shorter/simpler cycles of iterative development, rather than the old models of carefully spec'ing out each detail, taking forever to get it built, and then finding out that you had misunderstood the requirements
(often) or that the world around you had changed in the interim (also often, technology being what it is...)
--Chris
Chris Larsen
Architect, WebPulse Threat Research Lab
Symantec
From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org> on behalf of Bret Jordan <
Bret_Jordan@symantec.com>
Sent: Friday, February 1, 2019 1:50:15 PM
To:
cti@lists.oasis-open.org Subject: [cti] Relationship queries in TAXII
All,
During the F2F it was pointed out that one of the key features that is still missing from TAXII is the ability to pivot on data, meaning, the ability to ask the server for any relationships that match a specific SDO like a Threat
Actor, Campaign, Malware etc. Right now there is no way to do this in TAXII.
You may also remember that we had a discussion about this back in October and November and two proposals were discussed. Those propose were:
1) A proposal form Jason and Terry that is a full blown query object that would allows all sorts of queries and graph traversal
2) A very simple endpoint that would allow relationship queries and would follow the URL filtering syntax that we already have in TAXII
During our previous discussions it was pointed out that option 1 has been floating around for about 18 months, and has yet to garner any real support. The group on the working calls also thought that a simply and straight forward
approach, like option 2, might be a better choice for right now. During October and November we had strong support for option 2, however, there were two individuals that were vocally against it. As such, we elected to punt on it for Working Draft 05.
Given that this has resurfaced as the single biggest lacking feature in TAXII, I fell that we should talk about it one last time to see if the TC can agree on something for Working Draft 07 of TAXII 2.1. From my stand point I
see this as:
Option 1: Will take a considerable amount of time to figure out and get right. This will require some significant code work to verify that this will work and what issues will arise. This would be a major feature for TAXII this
late in the 2.1 cycle. I could also see this taking 6-9 months to get right and finished.
Option 2: While not ideal in the long-term and it does not allow all of the functionality of Option 1, it it something we could do in a matter of days rather than months. Most of the code needed to support this would be the same
as code that already exists in implementations. Yes, this may mean that down the road (1-2 years) if we end up doing option 1, that we either have two ways of querying a relationship or we end up deprecating this basic endpoint. But this would give us something
now, that people can use.
We plan on talking about this on next weeks working call. The options being:
1) Do we do option 1 and delay TAXII 2.1
2) Do we only do option 1 but do it in TAXII 2.2
3) Do we do option 2 now for TAXII 2.1 and look at option 1 later.
If you have strong opinions either way, please respond to this email.
Thanks
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.