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

I’m no expert on using algorithms as identifiers are moving to an adaptive model, but I can attest to the fact that tracking UUIDs over time for home grown
 content is a nightmare.  Until intelligence sources are very mature, they will face challenges with versioning.  De-duplication into “gold” objects melding all known intelligence together has been the solution we’ve been using for a while, but we haven’t tried
 turning that back into STIX… we just persist this in a custom ontology.

 

Thanks,

 

Alex

 

From:  [mailto:]
On Behalf Of Jerome Athias

Sent: Friday, November 13, 2015 4:33 AM

To: Jordan, Bret

Cc: Joep Gommers; 

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

 

At this stage I think we should consider algorithms to handle identifiers

We should also think about moving to an adaptive model

On Thursday, 29 October 2015, Jerome Athias <> wrote:

could be discussed aggregates, non-determinism and asynchrony

2015-10-29 19:55 GMT+03:00 Jordan, Bret <>:

> 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 <> wrote:

>

> While not in an sql world (deduplication),

> The Relationship object will help

>

> On Thursday, 29 October 2015, Joep Gommers <> 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-

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.