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


That becomes hard in an automated way and can become a denial of service.  I guess if there was a workflow piece that allowed someone to say that this is more accurate or has more information than something else.  

We see this problem in the AV sector today.  One piece of malware is called something different by every vendor when in reality it is all the same thing.

Bret 

Sent from my Commodore 64

> On Oct 29, 2015, at 2:45 AM, 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]