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

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.

John 
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
CTO
SOLTRA | An FS-ISAC & DTCC Company
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.  




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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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