OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Re: Relationship queries in TAXII


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]