I think people will get confused and ask why is their and InfomrationSourceType and an extra blob of data outside of it that also gives information about the Producer. Can we please have just one object that contains information about the Producer and where people can go to talk to that Producer?????
Thanks,
Bret Bret Jordan CISSPDirector 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."
Hi Mark, I’m torn between liking the idea of keeping direct references and not liking the idea. Liking them because: · The answer is right there! · There is no need for identity lookup at all · We have a ‘get out of jail free’ card of the stix_resolvers list if it doesn’t work. This might speed things up. Not liking them because: · They take up extra space in every object in addition to the Identity Object reference · It won’t take long to compute the same thing from the stix_resolvers, saving space · The references could become wrong over time. · Is the extra space consumed with the references array on high volume objects such as Observations and Indicators worth the few nanoseconds difference in computing the references from the Identity object stix_resolvers field? What do others think? Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company (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: {
"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_ref": "Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" // Omit field for anonymity
} {
"type": "identity",
"id": " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
"title": "Mark Davidson",
"stix_resolvers": {
"taxii2": "example.com", // Use DNS to identify TAXII Server & perform lookups ?
"amqp?": "amqp://user:pass@host:10000/vhost",
"sneakernet": "Ask Mark (555) 555-5555"
}
} My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve. Thank you. 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": { },
} 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 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!). 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. 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? 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
<image001.gif>"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.
|