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:
cti-stix@lists.oasis-open.org [mailto:
cti-stix@lists.oasis-open.org]
On Behalf Of Jerome Athias
Sent: Friday, November 13, 2015 4:33 AM
To: Jordan, Bret
Cc: Joep Gommers;
cti-stix@lists.oasis-open.org 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 <
athiasjerome@gmail.com > wrote:
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-
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.