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


Option 1 is certainly more “complex” as far as a single endpoint, however it would be done once and not have to be custom engineered for specific use cases. Option one can leverage existing standards and open source such as GraphQL, Gremlin or Sparql, so my, in fact, be already done or nearly complete – with existing technology support. However, re-inventing “queries and graph traversal ” would probably be a mistake.

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Sean Barnum
Sent: Friday, February 1, 2019 5:51 PM
To: Chris Larsen <chris_larsen@symantec.com>; Bret Jordan <bret_jordan@symantec.com>; cti@lists.oasis-open.org
Subject: Re: [cti] Re: Relationship queries in TAXII

 

I would vote strongly for Option 2 ASAP.

Option 1 shows promise but it also has significantly greater uncertainty and risk than Option 2. I agree that it will take a good deal of work and time to figure out if it will work as intended and have much greater impact if any major issues are discovered and need changing.

 

 


From: cti@lists.oasis-open.org on behalf of Chris Larsen <chris_larsen@symantec.com>
Sent: Friday, February 1, 2019 4:45 PM
To: Bret Jordan; cti@lists.oasis-open.org
Subject: [cti] Re: Relationship queries in TAXII

 

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]