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: [cti-cybox] [cti-stix] Re: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?

I’m with Rich – I’m not a fan of tying any kind of semantics to a version number. It would be terribly confusing for outsiders and newcomers. I think the approach that Trey defined is reasonable, as long as there’s the understanding that STIX doesn’t need to go through the same rigorous OASIS process (review period, etc.) just for a CybOX update release.

BTW, to Paul’s original point, I absolutely agree that CybOX will likely evolve and revision faster than STIX. However, I think there are some interoperability issues with supporting multiple versions of CybOX (even minor ones) at the same time, as Mark pointed out. As a consumer/producer, you would essentially have to define a compatibility matrix of the CybOX minor versions that you support, which could quickly get messy. Imagine that you support of CybOX 3.1, 3.2, 3.5, and 3.7 but not 3.3, 3.4, and 3.6, etc. and having to write code against that.


From: Rich Piazza <rpiazza@mitre.org>
Date: Thursday, May 12, 2016 at 10:15 AM
To: Bret Jordan <bret.jordan@bluecoat.com>, Trey Darley <trey@SOLTRA.COM>
Cc: Mark Davidson <mdavidson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, Ivan Kirillov <ikirillov@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: RE: [cti-cybox] [cti-stix] Re: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?

This can get confusing….


In the past we have had both a 1.1.1 release and a 1.2.1 release – neither which depended upon a new version of CybOX


Additionally, let say we go to STIX version 3 from 2.1.3, but CybOX is still on version 3.3.


Is the version of STIX 3.0.0 or 3.0.3?  Neither seems to work well – in the former case – the CybOX version is lost, in the latter case, it’s confusing – what happened to 3.0.0, 3.0.1, 3.0.2?


Let’s keep it simple – definitively rev the 3rd level, but don’t tie it to a CybOX version number.



From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, May 12, 2016 12:06 PM
To: Trey Darley <trey@SOLTRA.COM>
Cc: Mark Davidson <mdavidson@soltra.com>; Paul Patrick <ppatrick@isightpartners.com>; Kirillov, Ivan A. <ikirillov@mitre.org>; cti-stix@lists.oasis-open.org; cti-cybox@lists.oasis-open.org
Subject: Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?


Trey I like this idea... I would just propose a minor tweak...


STIX 2.0.0


1st digit = major STIX version

2nd digit = minor STIX version

3rd digit = minor CybOX version 




STIX 2.0.0 uses CybOX 3.0

STIX 2.0.1 uses CybOX 3.1

STIX 2.1.1 uses CybOX 3.1



We could also say that STIX does not actually need to revision when CybOX does, just in your spec_version conformance, you increment the 3rd digit to reflect which version of CybOX you are using.








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 May 12, 2016, at 05:52, Trey Darley <trey@SOLTRA.COM> wrote:


On 12.05.2016 11:41:25, Mark Davidson wrote:

I think the approach of allowing multiple versions of CybOX makes
conformance difficult. I do agree that CybOX could move faster than
STIX (especially if “adding an object” requires a revision to
CybOX), and that should be addressed by the CTI TC.


Allowing a new version of CybOX to be used in conjunction with an
existing version of STIX would mean that even though two
implementations supports "STIX 2.1”, one implementation might
actually have substantially different capabilities because it
supports a newer version of CybOX.

One potential solution would be:

 * STIX 2.0 depends on CybOX 3.0.
 * CybOX 3.1 is released with a bunch of shiny new objects.
 * STIX 2.0.1 is released, with no other change but to iterate CybOX
   3.0 to 3.1.
 * Rinse and repeat...

Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
"Every networking problem always takes longer to solve than it seems
like it should." --RFC 1925


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