[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: Embedded Content vs Referenced Content
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:
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.
Sean
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".
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."
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]