cti message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti] Re: Relationship queries in TAXII
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Chris Larsen <Chris_Larsen@symantec.com>
- Date: Mon, 4 Feb 2019 10:31:53 -0400
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]