[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Object ID format
(Copying the TAXII list because the topic has bled over)
I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a
topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information packages that contain policy information being redistributed arbitrarily (as long as those
movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within the protocol, anyway).
As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that hosted objects MUST have producer
information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain producer information. A key thing
for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.
An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this is good as one option for resolving content (connect to server->search for object). Adding to this
idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g., example.com instead of
https://example.com/taxii2/). I think that would possibly be a neat capability.
Updating the example, I could see:
{ {
-Mark
From: Terry MacDonald <terry@soltra.com>
Date: Saturday, January 23, 2016 at 1:08 AM To: Mark Davidson <mdavidson@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: 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: { ….. 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 ",
}, 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 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!). { Thank you. -Mark From:
<cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> +1 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> 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 And to go back further.... I still am of the opinion that we can't codify this without TAXII.
On Jan 22, 2016, at 07:43, John Anderson <janderson@soltra.com>
wrote: [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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]