Sorry – my message got truncated somewhere along the line. What I meant to say was:
Hi all,
+1 for making this easier to use, and focusing on simplifying it for new users and new vendors. I also agree that having a single document makes it far easier for developers to be able to make sense of STIX and CybOX as their relationship to each other will be obvious within the scope of the single document.
I am of the opinion that vendors will only update their software when a new version of STIX comes out, not when a new version of CybOX comes out. Vendors want to ensure interoperability, which means sticking with the most common ‘official’ releases. Most are wary of spending money constantly changing on updates, and will want the STIX and CybOX changes to happen at once. So having CybOX on an independent release cycle doesn’t make sense.
That said, TCP, UDP and ICMP are two different standards in two different files and they have worked fine…
How about we just keep a STIX document and a CybOX document and just merge the relevant CTI common information back into the STIX and CybOX documents.
This will ‘separate’ the documents again instead of intertwining them together via the CTI common doc as we have done now.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Terry MacDonald
Sent: Tuesday, 8 March 2016 8:01 AM
To: John A. Wunder <jwunder@mitre.org>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Documents
Hi all,
+1 for making this easier to use, and focusing on simplifying it for new users and new vendors. I also agree that havin
In database terms I would think about this as a denormalization optimization. Yes, these are different subject areas and maybe technically they should be separate.
But, Incident is also a different subject area from Indicator. We should optimize things because it makes it easy for human users, not because it academically makes sense to think of them as separate concepts.
More practically, it’s certainly doable to pull out parts of CybOX to be independently referencable even if they’re all part of a single work product. If anything
this can actually make MORE things easier to reference if we build it so that CybOX can be: right now you can pull out CybOX, but you can’t pull out Incident. Why? Why not just make it easy to reference any of these pieces within the specification?
I think it would also be worth saying what we want to get out of this. What I would like to see is:
-
I only want to look at one document, even if I have to ignore things in that document. Ignoring things is much easier than having to page through 3 (or, if we have 2 specs for each work product,
6) specs just to do STIX. Similarly, if I were developing a third-party spec IMO it would be better to reference one monolithic thing even if I ignore part of it rather than 2-3 independent (or, really, notionally independent but in reality very dependent)
things.
-
I want people to be able to reference the CybOX object library, Observation, Indicator, Incident, etc. from other specifications…not just the areas we think people should reference.
-
I want all of these core specs to be versioned in lockstep, rather than independently. IMO the value of being able to independently version them is much less than the value of having one consistent
version across everything.
If we can achieve those goals as separate work products I’m completely happy with that.
>One symptom of the split that I really don’t like is that certain TLOs will have a CTI Common spec version (relationship), others have a STIX one (Indicator),
and others have a CybOX one (Observation).
Well, I would assert this is one of the absolute intended advantages of the current approach. Common things should be defined and leveraged at a common level. Domain-spefic
things should be defined and leveraged at a domain-specific level. We do not want to force domains or implementers who only care about CybOX to have to think about domain-specific objects from STIX, or even worse domains that only care about CTI Common and
not about CybOX or STIX to have to worry about domain-specific objects from those two non-germane domains.
>That seems very confusing to me…one version to rule them all!
Again, I will assert that this is not a versioning issue. This is not about having different versions of the same thing. This is about having different things that
have different contexts and purposes.
I agree. In reality there are lots of interdependencies and they almost always version in sync anyway, so we might as well formalize that. It also simplifies how
we talk about things…how many times have you said “well that’s not really STIX, it’s CybOX, so XYZ rather than ABC”? This way we get rid of that issue.
I do agree with Paul’s (separate) concerns about references in, but I think by following what Allan and Bret mentioned we can avoid that and ensure that people
only deal with what they have to.
One symptom of the split that I really don’t like is that certain TLOs will have a CTI Common spec version (relationship), others have a STIX one (Indicator), and
others have a CybOX one (Observation). That seems very confusing to me…one version to rule them all!
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.
Right now, we have three documents for STIX & CybOX, aka CTI. We have:
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
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."
|