I think there are some key requirements/desires that we can tease out (Let me know if I have missed a key requirement):
- We want to keep things DRY [1]. IMHO this is the driving factor behind the CTI Common concept
- We want to enable downstream reuse of our work (e.g., MAEC)
- We want to claim conformance to ONE thing (not a matrix of things!)
- We want to enable some not-yet-quantified amount of change (e.g., new CybOX objects)
On the one hand, a single document is DRY, can be designed to allow downstream reuse, and provides implementors a single thing to claim conformance to. However, it is also the hardest to change – adding CybOX objects (for example) would be a tough process
and we’d probably end up with a bunch of revisions just for objects.
On the other hand, multiple documents are also DRY and can be designed to allow downstream reuse. However, implementers may have multiple things to claim conformance to. Change is easier because the changes will happen to a smaller document. On the negative
side, we end up with a set of tightly coupled documents – see my previous post (re: MAEC/CybOX). Additionally, as an example, the CTI Common 1.0 spec currently contains an indicator example – something defined in a “downstream” document – on page ~6.
In my mind, the middle ground concept looks like a possible solution. I will note the following easily addressable areas for improvement:
- It’s not called “STIX” (The thing people will recognize)
- It treats Observations differently than every other TLO in STIX (Indicator, etc)
- John Wunder’s additions seem to address this
- Plan for change is not yet defined. IMO there are at least two forms of this:
- How new CybOX objects get added
- How new combinations of existing objects get formalized (I can expand on this on the call today)
I also think, as I mentioned earlier, we should document what we feel will be our downstream users of the CTI specs and their requirements. Only with this information can we make informed decisions about how we organize our work.
Thank you.
-Mark
I prefer #2. While I still think a single document with independently referencable sections would be the best approach my primary concern here is just making sure it’s easy to understand exactly what a tool supports (or, from the producer side, what they
need to support). A world where people can support STIX 2.2 with CybOX 1.1 and CTI Common 1.0 seems very confusing to me.
We’d always talked about this back in the STIX 1.x days but with some exceptions for update releases (which we can do as errata) in practice these things tend to evolve side by side.
John
PS: I’ve alluded to this before but what I *actually* want is 1 spec document for STIX (including Observation and pattern) and 1 spec document, with subparts, for the CybOX object library. It’s never been clear to me how much value sharing “observation”
will be to things like MAEC or DFAX when the use cases are so wildly different.
Bret - That would work as well. We’ve seen and used this type of versioning for systems that have multiple components too.
allan
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."
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
+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."
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
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
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
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."
|