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?


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



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