OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: Re: [cti] Documents

I would agree that if CTI Common changes then any CybOX would need to be updated in order to be used with STIX if either one of them needed to update and use the new CTI Common. Seems to me that is the basic purpose of having a common “library” to be used across multiple things.
Is this a coordination issue? Yes.
Does that mean the solution is to merge all of these different things together? No. There are far more negative effects to smashing them together than any benefit offered on the coordination front. Merging them all together is the ultimate in tight coupling.

The reality remains that they are all still different things with different contexts/purposes. Different standards, groups or domains will still wish to use them separately.

>I don’t think I’ve seen evidence that CTI Common needs to be it’s own document, so let’s not make an artificial separation.

I believe this is very evident. Two very obvious examples of this are MAEC and DFAX which will want to leverage CTI-Common and CybOX but not STIX. If we design CTI Common well in a domain-unbiased way I think there is also strong potential that other non-OASIS representations (CVRF, CVE, CWE, CAPEC, even CIQ) could evolve to leverage CTI Common yielding much more interoperative integration across these domains.


From: <cti@lists.oasis-open.org> on behalf of Mark Davidson <mdavidson@soltra.com>
Date: Monday, March 7, 2016 at 1:42 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents

I think the current document organization introduces a tight-coupling scenario where a revision to STIX will basically force a revision to CybOX. This will happen any time that a STIX revision requires a revision to CTI Common. Given what CTI Common is supposed to contain, I feel like this scenario will almost certainly come up during the STIX 2.x/CybOX 3.x lifecycle.

Here is the scenario explained (It’s slightly complicated, bear with me):
If a change to STIX requires a revision to CTI Common, you’ll end up with e.g., STIX 2.1 and CTI 1.1. However, CybOX 3.0 will still depend on CTI 1.0. If you package all these together, you’d have STIX 2.1 depend on CTI 1.1 and CybOX 3.0; and CybOX 3.0 will depend on CTI 1.0. Therefore, in a single release of STIX, you’d have both CTI 1.0 and CTI 1.1. One solution to this would be to rev CybOX to use CTI 1.1.

As a bit of background, MAEC has been caught in this loop (between STIX/CybOX versions) for a while. MAEC is not in scope for the OASIS CTI TC, but I think we can learn from MAEC's history. I have cherry-picked the CybOX-related release notes from the MAEC change log (full release notes are at each URL).

The MAEC Object Type has been extensively reworked. It now extends the CybOX Object Type (MSD: CybOX 0.7)
The biggest change is that Cyber Observables _expression_ (CybOX™) v0.7 has now been replaced with CybOX v1.0
> The import and usage of the Cyber Observable _expression_ (CybOX™) Version 1.0 final.
> The import and usage of the Cyber Observables _expression_ (CybOX) v2.0
> Updated schemaLocation attributes to reflect the import and usage of the Cyber Observables _expression_ (CybOX) v2.0.1.

IMHO – let’s learn from history and avoid an unfortunate tight-coupling loop. I don’t think I’ve seen evidence that CTI Common needs to be it’s own document, so let’s not make an artificial separation. Note that I am NOT providing an opinion on how the schema files are organized – that is a different topic and there it might make sense to do something different.

Thank you.

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

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?



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

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