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'm sorry to be in disagreement, but I'm a -1 for this approach.  

Reading through these arguments, at a high level it seems great.  One spec to rule them all, but looking at how it would affect the broader community we are going down a dangerous path that will lead to lower interoperability and adoption by other domains.  

CybOX and CTI Common are broken out because of their value in reuse.  While we could pull them together into one huge standard this would be similar to pulling all of the [pick your favorite language] libraries into one single library.  Why use include statements when we can just include everything all the time?  The answer as anyone software developer knows is that it creates a tremendous amount of bloat.  The concept that some other domain, which only needs CybOX, would be comfortable including a library that includes all of STIX is similar to a developer being ok having to include every Apache library simply because they need ActiveMQ for message passing (an exaggeration, but you get the point).  

Keeping the specifications separate also allows other domains to know that they have a voice.  Even if CybOX completely fit their current day needs, any other domain would be warry of using it if it was fully embedded within the CTI specification.  How would this new (or current use cases such as MAEC or DFAX) know that their future concerns would have any weight in the future development of new CybOX objects when that specification is fully embedded within the CTI spec?  Would you trust that your future needs would be met if this was your domain?  We would be clearly strongly stating through our actions that CybOX is for CTI and any other user concerns may or may not be welcome.

Keeping the specifications separate is also valuable for the CTI domain as well.  During the F2F, it was made very clear that STIX 2.0 was going to be a major release that would be stable for many years to come.  While I fully expect that minor updates will happen, my hope is that this statement will be true.  Updates to STIX will be minor and infrequent.  CybOX on the other hand will continuously receive new updates.  New objects will need to be created, objects may need to be enhanced.  The creators of CybOX 3.0 stated that they are starting with a small subset of objects with the goal to add new objects over time.  This means that we now have 2 separate specs operating on very different release cycles.  The former, is having infrequent, small updates, while the latter is consistently adding new objects more frequently.  

It should be relatively easy to add in new objects into CybOX to increase the types of data we can share.  It should be relatively difficult to change STIX since many updates would require retooling our software and changing how CTI concepts are represented.  When you have everything bundled into one spec, it will be much easier to perform updates on STIX since we will be building frequent updates to CybOX.  It will mean that there is more to review each time there is a release and it will take longer to perform a review because of the size of the spec.  I don't know how many individuals here manage requirements documents, but those that do know that signing off requirements for a small system is much easier than getting a large requirements document reviewed and agreed upon.  We could state that self-restraint would have us only update CybOX objects on a regular basis, but we all know that if the mechanism exists for us to mess around with STIX as well, we're going to end up changing it up more than we should, resulting in larger review cycles and a less stable specification.  

Many of those on this list are or were software architects.  I would ask that we not abandon the principles of software architecture and lessons learned, such as developing for reuse, or separation of concerns, that have been developed over the years.  Is it more work to have to click on two specifications rather than one, yes.  Is it worth the risk of creating longer term maintenance, reducing community adoption and removing the mechanisms for maintaining separation between the responsibilities of CybOX vs. STIX.  I would argue no.

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Baker, Jon
Sent: Monday, March 07, 2016 4:02 PM
To: Wunder, John A.; cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] Documents


It seems like we can make it easy to refer to sections in one consolidated specification and enable the best of both worlds here. 

I don’t see CWE, CAPEC, or CVE as relevant to this conversation. I cannot say anything one way or the other about CVRF or CIQ.





Jonathan O. Baker

J83D - Cyber Security Partnerships, Sharing, and Automation

The MITRE Corporation

Email: bakerj@mitre.org

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, March 7, 2016 at 2:34 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents

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.


From: Sean Barnum <sbarnum@mitre.org>
Date: Monday, March 7, 2016 at 2:18 PM
To: "Wunder, John A." <jwunder@mitre.org>, Allan Thomson <athomson@lgscout.com>, "Jordan, Bret" <bret.jordan@BLUECOAT.COM>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents

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


From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, March 7, 2016 at 1:56 PM
To: Allan Thomson <athomson@lgscout.com>, "Jordan, Bret" <bret.jordan@BLUECOAT.COM>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents

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!


From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lgscout.com>
Date: Monday, March 7, 2016 at 1:45 PM
To: "Jordan, Bret" <bret.jordan@BLUECOAT.COM>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Documents

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.


	On Mar 7, 2016, at 9:14 AM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

	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]