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


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

 






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