Re: Moving content out of CTI-Common

["Jordan, Bret" <bret.jordan@bluecoat.com>]

Gary,

Thanks for the feedback... The discussion that has been taking place is to actually make sure CybOX and STIX are NOT tightly coupled.  

CTI Common, which we never had approval to create in the first place, caused CybOX to inherit a lot of complexity and STIX-ish things that really did not belong in CybOX.  CTI Common would actually make CybOX tightly coupled to STIX and cause problems for downstream solutions.

The current plan is to let CybOX go off and do its own thing, so that it can support MAEC, DFAX, and all of the other communities that need it without being beholden to STIX. One of the major discussions we have been having in Slack is where to draw the "line in the sand" between STIX and CybOX.  

Further, if there are any pieces from the STIX documents that CybOX "chooses" to use, they will just copy-n-paste those parts in to their own document, thus removing ALL of the weird coupling that you have called out.  By doing it this way, we actually can better address all of the concerns you have called out below.  

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 Apr 5, 2016, at 15:50, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil> wrote:

Bret,
   I object to the movement of CTI Common to be renamed as STIX Common and therefore removing the separation necessary to maintain the separate STIX and CybOX standards for their stated purposes.  CTI Common, as defined by the CTI TC github page, are "Common properties and values used by both STIX and CybOX."  The movement of CTI Common to be included inside of STIX creates large issues from a maintainability and reuse perspective.

   In your email, you reference the OASIS CTI Common Proposal which was voted down.  The Ballot question was, "Should we separate out common STIX / CybOX constructs into a new CTI TC work product called CTI Common."  Within the initial comments, Mark stated the following below:

"I will be voting no on the resolution as phrased. My position on CTI Common is that we currently don't have enough information to know whether it should be a standards-track work product. I am 100% on board with keeping the document and continuing work on it (i.e., what we have been doing) as a way to help answer these questions. My no vote does not constitute a vote to destroy the document/concept. I will list my open questions below, and I will change my vote if they can be answered sufficiently."

Your response was "Same comment as Mark."  John Wunder and others, including myself, agreed.  Mark's comment specifically stated "My no vote does not constitute a vote to destroy the document/concept."  When Mark, yourself, John, myself and many others voted, "no" we were voting based upon Mark's comment. Considering this clarification within the comments and agreement by the broader community, including yourself, on what a 'no' vote meant, CTI Common should not be unilaterally moved into STIX.

There are significant issues with making such a move.   

CybOX is used by more than just STIX.  It is also used by MAEC, and DFAX and has the potential in its current design to be used in the future by other standards.  By including CTI Common within STIX, we are also making CybOX dependent upon STIX, instead of only STIX dependent upon CybOX.  While many other future and current standards would have and currently have use for CybOX, fewer would have use for STIX.  

The CTI OASIS group is merely a steward of these standards.  We have a responsibility to the larger user base to understand their needs and do our best to meet them.  The movement of CybOX from MITRE to OASIS does not give us the right to unnecessarily destroy other use-cases for the standard.  

Movement of CTI Common to STIX creates the following issues:
1. It forces other standards that have a use for CybOX and CTI Common to also include STIX in their implementation when they have no need for STIX.
2. It makes other current or future standards that use CybOX or CTI Common, feel that their needs will not be represented in future releases of CybOX / CTI Common because it is tightly coupled to STIX.
3. Tightly coupling CybOX with STIX through 'STIX Common' violates the basic software design principle of modular programming.

On the flip side, I have been unable to find any argument for something that would break or not be possible to accomplish by not moving CTI Common into STIX.  Considering that even yourself stated that the 'no' vote to the CTI Common ballot did not signify that the document or concept of CTI Common should be destroyed, I would request STIX Common be immediately moved back to CTI Common since there is no mandate by the community for such a change to be allowed.

Thank you,
  Gary


-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Friday, April 01, 2016 1:21 PM
To: cti@lists.oasis-open.org
Subject: [Non-DoD Source] [cti] Re: Moving content out of CTI-Common

For the time being, I just renamed the document from CTI-Common 1.0 to "STIX Common" and added it to the bundle of STIX 2.0 pre-draft documents.  Over time, some of the elements in STIX common will need to be moved, to make them easier to find.  

I have also added this document to the Cover Page, so you can easily find it.  Other editorial things I have done today is I added a document status table and made other minor editorial changes to make it conform to the style guide of the rest of the STIX documents.



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 Apr 1, 2016, at 09:50, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

All,

Given the fact that the CTI Common ballot did NOT pass, we will start moving content from the old CTI-Common documentation back in to the STIX documents today.  





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