RE: [cti] Documents

["Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>]

Sorry to jump in so late in the discussion, but one thing that might be worth noting is that since both CybOX and STIX are moving toward an extension and relationship based model minor version changes should have a smaller impact on parsing compared to their earlier versions.

As long as a new CybOX version only adds extensions to the default library it will not break any existing tools that could parse STIX.  As unknown extensions could simply be skipped while the majority of data can still be safely gathered.  This might also work for new object types, but that would be dependent of the final implementation of STIX and CybOX.

Likewise moving to a relationship based model means that even if someone included some obscure homebrewed object and related it to a CybOX File object.   A compliant system would still be able to parse the file object even if it was unable to understand the home brewed one.

For example if a system was built to parse CybOX 3.0.0 which hypothetically defined object foo as:

{ 
  "id": *,
  "type": "foo",
  "basic":{
             "length": *,
             "width": *,
             "height": *,
             "unit": *
          }
}

If someone sent a CybOX 3.0.1 version of this including an extension for color which didn't previously exist you would get something like:

{ 
  "id": "foo-123",
  "type": "foo",
  "basic":{
             "length": 50,
             "width": 20,
             "height": 100,
             "unit": "ft"
          }
  "color":{
             "red": 40,
             "green": 105,
             "blue": 0
          }
}

The existing tool would still be able to process foo as a CybOX 3.0.0 object and get every piece of data that such an object would contain despite it being built using the 3.0.1 version of foo.  Extensions basically let us dynamically downgrade CybOX, STIX and MAEC objects across minor version, which makes it safer to keep the specs separated.

This would let the community who was interested in objects of type foo rapidly expand out its capacity without getting bogged down discussing unrelated object types.  Given how diverse the communities using these standards are I think that's a pretty huge win.

Note: If you are running in strict compliance mode where any document containing an unknown element or extension is rejected then this would not apply.

Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335


-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, March 08, 2016 9:45 AM
To: Jordan, Bret; Kirillov, Ivan A.; cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] Documents


>1) That which Allan Thomson proposed, and that be an artificial profile 
>version.  Meaning CTI v1.0 = STIX 2.0, CTI Common 1.0, and CybOX 3.0

I think makes sense and solves the version alignment issue without artificially conflating a bunch of things together that should definitely stay apart.

Another cleaner option is just to have the STIX 2.0 spec directly specify that it uses CTI Common 1.0 and CybOX 3.0.
This would be explicit and require no addition “profile” structure. The downside is that this would mean STIX 2.0 could never be used with any CybOX version other than 3.0 so if 3.1 was released before STIX 2.1 was released it would not be possible to use with STIX 2.0. The “profile” approach leaves open the option of defining a CTI v1.1 = STIX 2.0, CTI Common 1.0, and CybOX 3.1 if desired. I am not saying it would be desirable, only that it would be possible.

I continue to assert that #2 is not an option for the reasons I have provided and the additional thoughts reasons provided by Ivan, Gary and Paul.

sean



From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Monday, March 7, 2016 at 7:50 PM
To: Steve Cell <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents


Is there a middle ground....?  Two options I see are:  

1) That which Allan Thomson proposed, and that be an artificial profile version.  Meaning CTI v1.0 = STIX 2.0, CTI Common 1.0, and CybOX 3.0


2) A single CTI specification that has multiple work product documents inside it.  Example:
CTI 1.0
- Common
- STIX
- CybOX

Then a resulting product / marketing material could say they support CTI 1.0.  Also, something like MAEC could say they support CybOX from CTI 1.0.  


If we went with option 2, then another option could be even more granularity, meaning break STIX out in to major TLO sections.  This would make reading and consumption be easier, especially for organizations that are only ever going to use a subset of the spec.  





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 Mar 7, 2016, at 16:58, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

	I would much prefer to have separate documents; with regards to use of specific components, I think it would be MUCH cleaner for something like MAEC to say that it depends on and uses CTI Common, CybOX Core, etc. rather than some subsections of an amalgamated document. It seems like the main argument in favor of this approach is that it’s easier for human consumption; however, I think this also has the potential to make this more difficult, since it will entail an even larger rift between the specifications and granular JSON schemas. E.g., if I’m familiar with only the JSON schemas, it’s not very clear as to where there specification that drives a particular schema is defined. It’s also worth remembering that CybOX will have 40-something Objects defined for 3.0, which would take up a substantial chunk of the document.

	As far as versioning, I agree with John and the others that we should strive to have a single version across all CTI language components (common/CybOX/STIX). Having independent versions in the past has caused some painful dependency issues (as Mark alluded to). Also, for those not familiar, previous versions of CybOX support having independent versions of its Objects (e.g., Address v2.1, Process v3.0, etc.); for CybOX 3.0 and going forward I’d like to get away from this and have the same version across all CybOX components (Core/Common/Objects).

	Regards,
	Ivan

	
	From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <bret.jordan@bluecoat.com>
	Date: Monday, March 7, 2016 at 4:21 PM
	To: Allan Thomson <athomson@lgscout.com>
	Cc: Sean Barnum <sbarnum@MITRE.ORG>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
	Subject: Re: [cti] Documents
	

	
	
	+1
	
	
	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 Mar 7, 2016, at 16:18, Allan Thomson <athomson@lgscout.com> wrote:

		Hi Sean -  

		Appreciate your response. I understand that each of the 3 documents are not the same content. I also understand the relationship between them.

		What I meant by “version” was that when an implementer wants to implement STIX version X they also need to implement CTI Common 1.0 and CyBOx 3.0. And they have to know what versions of each of the 3 documents they are building a product on. 

		I can see arguments for and against having them be separate documents. 

		But I still lean towards having a single document that contains 3 separate sections with ONE version for the combined content.

		Subsequent updates to CyBox content would just update the content of that section in the document and a new version of the combined STIX could be generated.

		So instead of a testing matrix hell that would have 3 trains (CTI Common, STIX and CyBox), I think one train is better. STIX 2.0, STIX 2.1, STIX 2.2….etc.

		Allan






			On Mar 7, 2016, at 11:11 AM, Barnum, Sean D. <sbarnum@MITRE.ORG> wrote:

			Allan, I would like to point out a concern I have with the way you characterize things below.

			We are not talking about “versions” of a single body of content.
			We are talking about completely different bodies of content. 
			Are their interrelationships between them? Yes.
			Are they all the same thing? No.
			Are there clear reasons why they should be different things? Yes.
			Are there other bodies of content that will want to relate with one or two but not all three of these bodies of content? Yes.

			Characterizing this issue as a versioning issue is, I believe, inaccurate and misleading.
			I do not think that was your intent but I believe that it could be the result from some reading your post.

			sean

			
			From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lgscout.com>
			Date: Monday, March 7, 2016 at 1:45 PM
			To: "Jordan, Bret" <bret.jordan@BLUECOAT.COM>
			Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
			Subject: Re: [cti] Documents
			

			Having a single version of the content is preferred from my perspective.

			You can still have normative text that describes each module separately.

			But having ONE version to track for the related content is preferred.

			allan


				On Mar 7, 2016, at 9:14 AM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

				Right now, we have three documents for STIX & CybOX, aka CTI.  We have:

				CTI Common 1.0
				STIX 2.0
				CybOX 3.0

				I would like to challenge this design.  It seems like we are opening ourselves to document versioning and compliance / interoperability nightmares. 

				1) Does it really make sense, other than for historical reasons, to keep these documents separate?  

				2) If they were merged, then could not things like MAEC and other standards (that are NOT part of OASIS) just reference the sections that were of interest to them?



				
				
				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: smime.p7s
Description: S/MIME cryptographic signature