OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-stix] Embedded Content vs Referenced Content

We can have our cake and eat it too.

All objects need reference ID’s and be globally reference able (i.e., globally unique ID’s).

One can always choose to embed such objects, so long as you reference them through their ID’s. The model I am thinking of is MIME’s Content-ID and Content-Location (see RFC 2392).

On Aug 21, 2015, at 2:04 PM, Barnum, Sean D. <sbarnum@mitre.org> wrote:

I agree with Aharon here that we do not need any sort of formal motion to have a discussion.
I think the only key prerequisite we should try to tackle for all topics of interest like this is to ensure we have an issue in the tracker for it such that discussions on the list can refer to it and key results/opinions from the discussion can be captured in it.

As I have stated before when we have been discussing this issue, I have no strong personal preference either way.
If we were forced to choose one and only one approach (embedding or referencing) we would need to choose referencing to enable effective reuse and pivoting.
Embedding has also been an option to date for two main reasons:
  • The need for it has been expressed by various stakeholders in the community to support requirements/issues of ease of use or perceptual encapsulation for their use cases since we began the STIX/CybOX efforts.
    • I have stated many times that I think that this limitation should likely be possible to overcome through effective UIs that allow producers and consumers to deal with content through a lens of perceptual encapsulation even if the back-end representation is disintegrated/distributed (by reference). We just need to be sure that everyone understands if we make such a decision we are pushing responsibility for addressing this to each and every implementation.
  • Non-insignificant complexities of versioning and data marking of disintegrated/distributed (reference only) representations of perceived atomic content.
    • I do not believe we have adequately thought through and discussed this limitation and therefore I am unaware of any current answer to this on the table. I would further assert that, while not impossible, I do not think it will be a simple or quick exercise.
Any discussion or deliberation regarding this topic will by necessity need to address these two factors and have clear rationality/justification why these are no longer relevant concerns or be able to provide effective and compelling solutions to addressing them.

This is a good example of the sorts of things that look simple and obvious on the surface but may not be so obvious when the full context of the real-world is considered.
That is not to say that the simple or obvious looking answer is always wrong but it is absolutely imperative (especially within any sort of formal standards governance) that we not jump to any conclusions and that we carefully and deliberatively explore all of the potential needs, implications and impact and make wise and informed decisions.

I have been told that there might be a few people within the SC that have the perception that Aharon and myself are attempting to slow-roll things or prevent progress on STIX evolution.  Let me very clearly state that nothing could be further from the truth. We are very interested in and dedicated to advancing STIX as fast as we can appropriately do so. It is our responsibility as co-chairs within OASIS to ensure we do so in accordance with the principles described in the preceding paragraph above. I am sure that it may be frustrating for very eager folks who want to move at Mach speed, but I ask for your understanding, your patience, and your willingness to work with us to move forward as fast as we can.

I look forward to the chance to dig into all of these issues with you and work together to find the best path forward.


From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, August 21, 2015 at 12:27 PM
To: John Wunder <jwunder@mitre.org>
Cc: Aharon Chernin <achernin@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Embedded Content vs Referenced Content

Good points John.  To be clear I do not believe there is really a problem for producers.  The problem I am trying to address is for consumer.  Doing as Aharon has suggested in STIX 2.0 would greatly decrease the complexity for a consumer.  This proposal along with others, can really move the needle and help us gain adoption.  

Here is a thought exercise to illustrate some of the problems we face.  Imagine 20 very desperate producers of STIX & CybOX content and a single consumer, where some level of trust exists between all parties.  The consumer gets a series of arbitrary STIX 1.2 + CybOX documents from the producers where the content can containing some or all of the idioms. Keep in mind the enormous amount of optionality, the multiple ways of doing things in STIX and CybOX, and the ideas that some content can be embedding or referencing when thinking about this.  

Now start writing a decision tree in code, say in C or C++,  to process these arbitrary STIX documents to pull something actionable from them.  If you do not write code, this may appear to be easy, so ask one of your developers to help you.

I strongly support the ideas that Aharon has called out below for STIX 2.0.  I would also challenge the community to look for ways to reduce optionality and honestly adopt core values of "simplicity" and "one way of doing things".  



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 Aug 21, 2015, at 08:50, Wunder, John A. <jwunder@mitre.org> wrote:

I agree with all of Aharon's points. This will make some content slightly more wordy/complicated for producers, but MUCH simpler for consumers. And, across all users, it would make it easier to understand.

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Aharon Chernin <achernin@soltra.com>
Sent: Friday, August 21, 2015 8:13:54 AM
To: Jordan, Bret; cti-stix@lists.oasis-open.org
Subject: [cti-stix] Re: Embedded Content vs Referenced Content
Don't think we need to make motions to have discussions. 

My hope is that we think about it this way:

* If you are an object, you have an ID
* Any contextual object that needs to include another object, should be required to use an ID_REF (no embedding)
* Any object that creates relationships/groups of data should use ID_REF (no embedding)

Aharon Chernin
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Thursday, August 20, 2015 4:15 PM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Embedded Content vs Referenced Content
Returning the sightings thread back to its originally scheduled program. 

In the spirit of what is become our defacto core values, "one way of doing things" and "easy to understand and use", I would like to make a nominal motion that for STIX 2.0 we investigate where it makes sense to restrict objects to be either "embedded content" or "referenced content".  Further, a long these lines is to make the ID value be required where it makes sense. 

The one example is the Report Object, but I am sure all top level objects should be looked at as well.  



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." 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]