CTI STIX Subcommittee

(Sorry for the double reply to the topic)


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. 


In the scenario where a “newer CybOX" implementation sends information to an “older CybOX" implementation, the “older CybOX" implementation will either reject the payload (because it has unknown fields) or drop part of the payload on the floor (because
this is JSON and that’s how we do things). In both cases, two things that say “STIX 2.1” on the label will not interoperate the way people expect.


Maybe I’m missing something, but I just don’t see how allowing arbitrary CybOX versions is workable unless we invent a general purpose “anything can go here” extension point, complete with media types.


Thank you.
-Mark








From: < cti-cybox@lists.oasis-open.org > on behalf of Paul Patrick < ppatrick@isightpartners.com >
Date: Wednesday, May 11, 2016 at 8:29 PM
To: "Kirillov, Ivan A." < ikirillov@mitre.org >
Cc: " 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: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?






Ivan,


Actually I could see CybOX evolving faster than STIX due to the fact that CybOX has more potential consumers (MAEC, DFAX, OpenC2) that would drive faster evolution than STIX. If we follow the rules for evolution that minor revisions
MUST backwards compatible with previous versions and any incompatible change requires a major release, why wouldn't we need the spec_version and that the dependency from STIX would be to a specific major version and a base minor version from which later minor
versions could be used?

Sent from my iPhone

On May 10, 2016, at 3:07 PM, Kirillov, Ivan A. < ikirillov@mitre.org > wrote:




At this point I think the assumption has been that a particular version of STIX would support a particular version of CybOX, and only this version.


E.g.,

STIX 2.0 would support CybOX 3.0 STIX 2.1 would support CybOX 3.1 Etc.
Does this align with the existing community perceptions? Are there any particular needs or cases where STIX would want to support multiple versions of CybOX at one time? The only hypothetical example I can come up with is if STIX incorporates data from
another source, such as MAEC, that uses a different version of CybOX. However, I would imagine that, for compatibility reasons, STIX would only want to incorporate data sources that use the same version of CybOX that it uses.


This came about from some recent discussions in CybOX about the spec_version field and whether we need to incorporate it in the CybOX Container/ArgleBargle. If the assumption is that STIX, MAEC, and other CybOX users will only support a particular
version of CybOX for any one release, then perhaps this field isn’t needed.


Regards,
Ivan

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. > Agreed. > > 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... -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925 Attachment: signature.asc Description: Digital signature

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  Thus 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. 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 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. Agreed. 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... -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- Every networking problem always takes longer to solve than it seems like it should. --RFC 1925 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

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.


Regards,
Ivan









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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

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.


Regards,
Ivan









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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

I agree. A specific version of STIX can just reference a specific version of CybOX…we don’t need to have strict rules about which components of a version number correspond to that. If we update from STIX 2.0.1 to 2.1 and both want to reference CybOX 3.1,
that should be fine (IMO).









From: < cti-cybox@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Thursday, May 12, 2016 at 12:15 PM
To: "Jordan, Bret" < 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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

I agree. A specific version of STIX can just reference a specific version of CybOX…we don’t need to have strict rules about which components of a version number correspond to that. If we update from STIX 2.0.1 to 2.1 and both want to reference CybOX 3.1,
that should be fine (IMO).









From: < cti-cybox@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Thursday, May 12, 2016 at 12:15 PM
To: "Jordan, Bret" < 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 3 rd 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 


 


Thus


 


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.








 


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 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.


Agreed.






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...

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




 

What parts of CybOX do we expect to change frequently? Is it the core language or is it the list of objects? I feel that the answer to that question will have an impact on the solution for handling change.


Thank you.
-Mark








From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Thursday, May 12, 2016 at 12:05 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-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?






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 


Thus


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.











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 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.



Agreed.


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...

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

What parts of CybOX do we expect to change frequently? Is it the core language or is it the list of objects? I feel that the answer to that question will have an impact on the solution for handling change.


Thank you.
-Mark








From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Thursday, May 12, 2016 at 12:05 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-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?






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 


Thus


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.











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 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.



Agreed.


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...

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

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  Thus 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. 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 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. Agreed. 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... -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- Every networking problem always takes longer to solve than it seems like it should. --RFC 1925 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

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. > Agreed. > > 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... -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925 Attachment: signature.asc Description: Digital signature