Re: [cti-stix] Object ID format

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

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, January 21, 2016 at 7:25 AM
To: "Thompson, Dean" <Dean.Thompson@anz.com>
Cc: "'Jordan, Bret'" <bret.jordan@bluecoat.com>, 'Terry MacDonald' <terry@soltra.com>, 'John Anderson' <janderson@soltra.com>, "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] Object ID format

Agree as well - that was the concensus at the F2F - ID should be for ID purposes, information source for producer purposes.

-
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

"Thompson, Dean" ---01/21/2016 01:06:58 AM---Hi!, I definitely support the use of the InformationSource object. It has the capability of providi

From: "Thompson, Dean" <Dean.Thompson@anz.com>
To: "'Jordan, Bret'" <bret.jordan@bluecoat.com>, "'Terry MacDonald'" <terry@soltra.com>
Cc: "'John Anderson'" <janderson@soltra.com>, "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org>
Date: 01/21/2016 01:06 AM
Subject: RE: [cti-stix] Object ID format
Sent by: <cti-stix@lists.oasis-open.org>

Hi!,

I definitely support the use of the InformationSource object. It has the capability of providing great context which is sometimes lacking in STIX documents.

Regards,

Dean

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, 21 January 2016 3:56 PM
To: Terry MacDonald
Cc: John Anderson; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

And we can not have one group do it one way, and another group do it some other way. This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID. What we found from the discussion is that at the end of the day, the domain name in the ID did not really provide any value. What is important is that the Information Source object be there.. This will enable people those groups that want open communication to be found. It will also allow those groups that do not want attribution or want to hide, to hide.

The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object.

Thanks,

Bret

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 20, 2016, at 19:35, Terry MacDonald <

terry@soltra.com

> wrote:

Hi John,

The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA

| An FS-ISAC and DTCC Company

+61 (407) 203 206 |

terry@soltra.com

This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

cti-stix message