Re: [cti-stix] Object ID format

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I like the "Exports" approach better than the relationship tag approach, but am not strong on it and could go either way.

The reason I like exports is because I only have to export the mapping once; if we have to do it in relationship then in a very big STIX report we could be saying the same thing over and over and over.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Wunder, John A." ---01/21/2016 09:48:45 AM---The one caveat I would add here is that we need to make sure we can provide an information source fo

From: "Wunder, John A." <jwunder@mitre.org>
To: "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org>
Date: 01/21/2016 09:48 AM
Subject: Re: [cti-stix] Object ID format
Sent by: <cti-stix@lists.oasis-open.org>

---

The one caveat I would add here is that we need to make sure we can provide an information source for things we want to relate but don’t own. I think this is the scenario Terry is worried about.

Example:

Terry publishes Indicator ABC and relates it to Malware XYZ
Jason publishes Malware 123
I realize that Indicator ABC is actually also detecting Malware 123, a variant of XYZ. I want to share this, but I also don’t want to have to re-share Malware 123 or Indicator ABC. So I just share a relationship object:

ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware

It would be nice if we had some way of indicating that you can go get more information on indicator:ABC from Terry and on malware:123 from Jason. Terry’s suggestion was to add an optional information source to the from and to values:

ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
From_Source: Terry
To: malware:123 [produced by Jason, but you don’t know this from the ID]
To_Source: Jason
Information Source: Me
Value: Indicated Malware

That would let you look up the other ends, and that data would follow the relationship object into your repository. That makes it very easy to look it up down the road if an analyst clicks a “more info” button.

OTOH, one thing Gary Katz suggested at the F2F was an “exports” definition on messages that would do the same thing:

Message: Announcement
Relationships:
ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware
Exports:
indicator:ABC => Terry
malware:123 => Jason
relationship:UUID-1 => John W.

That approach keeps the extra fields out of the relationship, but the downside is that they don’t follow the relationship into your database so you’d have to track them separately. OTOH, we could map them not just to an information source but to an actual TAXII server, while still keeping the actual STIX/CybOX content agnostic of TAXII. It’s a toss-up to me…last night when we talked Terry had me convinced that the first approach (with the producer IDs in the relationship) was better while after writing it out today maybe I’m thinking the opposite. I’m curious what you all think of these two approaches.

There are also reasons that Gary outlined for why proxy anonymization doesn’t solve the problem, specifically related to de-duplication. I think I can explain that if anyone is curious but I don’t want to crowd the thread.

John

[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]