OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[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


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]