Thanks for the quick response. There are 3 areas associated with CTI Common listed on the github page:
1. Core Object Properties:
"The fields that apply to all too-level objects across STIX and CybOX."
"Developing an approach for how CybOX objets can be used for patterns in STIX indicators as well as other places"
"Determining how top-level objects in STIX and CybOX are versioned."
All 3 of those topics in their definition relate to how both STIX and CybOX would use the concepts within CTI Common. Coincidentally, concepts such as Versioning and Patterning would also be useful for other standards that are built upon CybOX. For example,
malware analysis represented in MAEC would could implement versioning in the same way that STIX does, increasing compatibility.
I would also disagree that we should be copying and pasting reusable components into both STIX and CybOX. From a software development standpoint, could you imagine having developers copying and pasting reusable code across multiple projects or even different
components within the same system? It creates maintenance nightmares. Its why we have shared libraries in the first place.
Either way, there seems to be a disagreement on the mandate to allow such a change to occur. Until we are able to drive to consensus and alleviate some of the concerns that myself and others are having, I would propose that we should not be making wholesale
From: Jordan, Bret [mailto:email@example.com
Sent: Tuesday, April 05, 2016 6:05 PM
To: Katz, Gary CTR DC3/DCCI
; Chet Ensign (firstname.lastname@example.org
Subject: [Non-DoD Source] Re: Moving content out of CTI-Common
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
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.
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.email@example.com
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
] On Behalf Of Jordan, Bret
Sent: Friday, April 01, 2016 1:21 PM
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.
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
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.
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."