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-
