Very valid point Allan, I missed that option. Sorry about that. Anyways, we will discuss this on next weeks working call.
Bret
Sent from my Commodore 64
PGP
Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Feb 1, 2019, at 4:41 PM, Allan Thomson <
athomson@lookingglasscyber.com > wrote:
Bret How you state Option 2) is confusing because it implies preferring Option 1) if you want to ship TAXII2.1 now.
I have no strong preference (yet) on Option 1) or 2) in the future but I think TAXII2.1 can be useful without either of them.
So suggest:
Option 4) Ship TAXII2.1 as-currently drafted without any relationship/query options in it.
Given that there seems to still be debate on either simplified reln query or full-blown query endpoint Option 4) might be worth considering.
Allan
From: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
on behalf of Bret Jordan <
Bret_Jordan@symantec.com >
Date: Friday, February 1, 2019 at 12:50 PM
To: "
cti@lists.oasis-open.org " <
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