Re: Moving content out of CTI-Common

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

The topics of patterning, and where it should exist is currently being actively debated..  Versioning was talked about and it seemed like it might be dropped from CybOX as it is really only a STIX item.  CybOX is just the facts as Sean always said.  

The point is, as you rightly call out, there is a lot of unknowns right now and a lot of things that need to be figured out.  Once we figure out where things should be, we can better address how to get there from a documentation standpoint / work product stand point.  

To your one point about software re-use and OO principles.  That is only true beyond a certain point.  If all you need is one method from a library that contains 5000 methods and that method is super small, than some times it is better to just re-implement it instead of taking along all of the baggage.

At the end of the day, we never had approval to create CTI Common in the first place.  We are trying to fix that mistake.  If, before this standard is done we find that we really do need something like it and it make sense to have (meaning conformance clauses can actually be written for it), then we will ask the TC and OASIS for permission to create it.  We will do it right, not ad-hoc like we did before. 

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 16:23, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil> wrote:

Bret,
  Thanks for the quick response. There are 3 areas associated with CTI Common listed on the github page: http://stixproject.github.io/stix2.0/

1. Core Object Properties:
"The fields that apply to all too-level objects across STIX and CybOX."

2. Patterning:
"Developing an approach for how CybOX objets can be used for patterns in STIX indicators as well as other places"

3. Versioning
"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 changes.

Thanks,
  -Gary

-----Original Message-----
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Tuesday, April 05, 2016 6:05 PM
To: Katz, Gary CTR DC3/DCCI
Cc: cti@lists.oasis-open.org; Chet Ensign (chet.ensign@oasis-open.org)
Subject: [Non-DoD Source] Re: Moving content out of CTI-Common

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