[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX versioning as an interim solution to deduplication
could be discussed aggregates, non-determinism and asynchrony 2015-10-29 19:55 GMT+03:00 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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]