RE: [cti-stix] Object ID format

Hi Mark,

Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.

Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly. Both of these options have their problems. The first results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

I think your idea is excellent Mark, and with a little tweak could be even better….

Idea: What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

An illustrative example….

If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref field pointing to the Identity object of who made and published the STIX object:

{
  "type": "indicator",
  "id": "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29",
  "stix_producer_ref": " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity

  …..
}

Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more information about STIX objects that this identity has produced:

}

"type": "identity",

  "id": " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",

"title": "Mark Davidson",

"stix_resources": {

                 "taxii2": "https://example.com/taxii2 ",
                 "amqp?": "amqp://user:pass@host:10000/vhost",
                 “sneakernet": "Ask Mark (555) 555-5555"

},
}

There are some really great benefits to having this kind of structure.

1. If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!

2. If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by the Organization (apart from the Identity one).

3. If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all that needs to be done is a new revision of the Identity object with a modified stix_resources section!

Simple!

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. <jwunder@mitre.org>; Foley, Alexander - GIS <alexander.foley@bankofamerica.com>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Jordan, Bret <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>; Trey Darley <trey@soltra.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).

{
  "type": "indicator",
  "id": "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29",
  "references": {"taxii2": "https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29",
                 "amqp?": "amqp://user:pass@host:10000/vhost#SomeOtherStuff",
                 “sneakernet": "Ask Mark (555) 555-5555"},
  "producer": "MarkDavidson" // Omit field for anonymity
}

Thank you.

-Mark

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>, Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.

John

From: <cti-stix@lists.oasis-open.org> on behalf of "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>, Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] Object ID format

I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time? That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.

STIX co-chairs, what’s the plan for gaining consensus on the object id?

Alex

From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.

This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

-
Jason Keirstead
STSM, 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

"Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: John Anderson <janderson@soltra.com>
Cc: Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 01/22/2016 12:03 PM
Subject: Re: [cti-stix] Object ID format
Sent by: <cti-stix@lists.oasis-open.org>

Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.

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 22, 2016, at 07:43, John Anderson <janderson@soltra.com> wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.)

JSA
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

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.

cti-stix message