Re: [cti-stix] STIX versioning as an interim solution to deduplication

["Jordan, Bret" <bret.jordan@bluecoat.com>]

The problem with de-dup is harvesting all of the nuggets of extra information that are tied to the references that you are about to throw away.

Bret 

Sent from my Commodore 64

On Oct 29, 2015, at 5:38 AM, Jerome Athias <athiasjerome@gmail.com> wrote:

While not in an sql world (deduplication),

The Relationship object will help

On Thursday, 29 October 2015, Joep Gommers <joep@eclecticiq.com> wrote:

Dear All,

I’d like to ask for your opinion.

Use-case; many producers create intelligence with widely different content (names/meta/context) for the same threat information. Additionally, many producer don’t re-use or across producers we don’t re-use STIX IDs. Therefor, the challenge of duplication is significant. 

While we’ve already have many non-STIX way of dealing with this at EclecticIQ, I wonder if STIX versioning idioms aren’t a way to accomplish part of this.

Example;

Before:

TTP A: Zeus, version 1 – namespace vendorA

TTP B: Zeus, version 1 – namespace vendorB

TTP C: Zeus, version 1 – namespace vendorC

After:

TTP D: Zeus version 1 – my own namespace

Related TTPs

Supersedes IDREF TTP A version 1

Supersedes IDREF TTP B version 1

Supersedes IDREF TTP C version 1

Basically telling my STIX authority that TTP A/B/C version 1 no longer should be current and then TTP D version 1 (my analytic decision that my Zeus is now all other Zeus) is actually analytically equal to the others?

J-