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] RE: Some additional thoughts on combining STIX and CybOX

Hi Sean and all, 

Let me help out with definitions here and try to give you a framework for thinking about work within the context of the OASIS process. In the OASIS TC Process at https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess you'll find how TC work products progress and you may also want to look at the relevant definitions at the start of that document. 

OASIS divides the content TCs produce into two streams: standards track work products - works that are essentially on the path to OASIS Standard - and non-standards track work products - works that are informative, explanatory, etc. in nature and meant to supplement or support the standards track works and will become Committee Notes. Let's focus on the standards track work products for now. 

Quickly, on Subcommittees, keep in mind that in every case, a work product is an output from a Technical Committee. Subcommittees are simply groups formed within a TC to help facilitate getting things done. SCs have a scope defined by the TC - so in effect, as Sean says above, they can be chartered to work on one or more documents or work products as the TC decides. SCs can produce drafts, even complete working drafts, but they cannot approve them for the TC. All a SC can do is bring a work product back to the TC and present it for the TC's consideration and, if desired, approval. 

A standards track work product is a conceptual 'thing' that may consist of a single narrative document or may consist of a collection of documents and associated files such as UML models, schemas, header files, JSON files, code samples, etc. MQTT Version 3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) for example is an OASIS Standard that consists of a single document published in the three required formats: editable source, HTML, and PDF. STIX Version 1.2.1 (http://docs.oasis-open.org/cti/stix/v1.2.1/csd01/) is as you all know a work product with 15 parts plus the UML model. From our perspective, the work product the TC is working on and, in due course, approves is STIX V1.2.1 in toto. (One of the implications of this by the way is that work products don't have shared parts. STIX V1.2.1 is a single work product. TAXII V1.1.1 is a single work product. You can't have a part that lives somehow shared between them. They may have copies of common content or the STIX work product may reference a part in TAXII and vice-versa. But they can't share a part between them.) 

Standards track work products start life as working drafts (WD). These are local to the TC and, while visible to the public, are not yet approved work products. 

With recorded, minuted or balloted, Full Majority Vote approvals by TC Voting Members, the working draft becomes a Committee Specification Draft (CSD) and can be released for as a Public Review Draft (CSPRD). These steps can iterate as many times as needed. Once you deem the work product ready, the TC can request a Special Majority Vote (as you have) to approve The CSD as a Committee Specification (CS). A Committee Specification is considered an OASIS Final Deliverable and, on approval, all the obligations and protections of the TC's chosen IPR mode lock in. From there the CS can, after three or more Statements of Use are accepted by the TC, be approved for presentation to the OASIS members as a Candidate OASIS Standard (COS). This undergoes a 60 day public review at the end of which a membership ballot is held and if it passes the work product then becomes an OASIS Standard. 

So, to summarize: 

- A document is simply a file with contents that one or more people are writing and that may become part of a work product. 

- A work product is one or more documents plus any other components that is intended to become an approved output of the TC. 

- A working draft is the first step in the evolution of a work product on its way through the TC Process workflow as either a standards track or non-standards track output. 

- A 'specification' is just a convenient term for characterizing some work product as being in the standards track. No harm in calling something a 'specification' but it doesn't have a formal meaning in the OASIS workflow. I'd avoid using the word 'standard' though since that might be confused with "OASIS Standard" which doesn't exist until the end of the process. 

I hope this helps clear up any confusion. Please let me know if you have any questions on it. 



On Thu, Mar 17, 2016 at 2:34 PM, Barnum, Sean D. <sbarnum@mitre.org> wrote:
Jason, I agree with you on the confusion between document, work product, subcommittee and standard.

Here is my take based on my understanding of OASIS rules (Chet and company feel free to point out where I may be wrong):
  • A standard is some work product within a TC that is put forward for official committee specification or full OASIS standard vote
  • A subcommittee is merely a subdivision of the TC’s responsibility space focused on a particular topic area and may pursue one or more work products and has one or more assigned responsible chairs
  • A work product is an official document or set of documents focused on specifying some particular information which may be normative or informative and has an assigned responsible editor
  • A document is a single “document” focused on specifying some particular information and may form the entirety or only part of a given work product
I think the key takeaways are that a work product may consist of one or more documents, a work product does not necessarily imply a standard is being pursued, an SC may pursue one or more work products, etc.

A key intent of my post below was to deconflate the issues of “documents” and “standards”. Combining STIX and CybOX would not simply be a documentation issue. It would be forcing a combination all the way up the above stack.
Similarly, the comments on the ballot for CTI Common lead me to believe that there is significant confusion on the difference between a work product and a standard. The ballot does not assert that CTI Common should be a separate standard, only that it should be a separate work product. The TC would be free to decide at any future date whether or not it should ever go forward as a standard and would also be able to define both the STIX 2.x and the CybOX 3.x work products as explicitly including the CTI Common work product if desired. Making it a separate work product just removes the ambiguity of its purpose and who is responsible for it.

Thank you for pointing out this confusion.


From:  <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, March 17, 2016 at 1:59 PM
To: "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Subject: Re: [cti] RE: Some additional thoughts on combining STIX and CybOX

I just want to throw it out there that having separate working documents does not necessarily mean we have to have separate work products. Also, having separate work products and/or working documents, does not necessarily mean we either have to (or conversely, can not) have separate subcommittees that are maintaining those working documents and/or work products.

Tl;DR - People are confusing working documents, work products, and subcommittees too much in this thread. Lets be clear on what we're talking about.

I also agree Cybox should be a separate work product, because it has lots of usefulness outside of STIX (including the potential to create a common cyber-threat correlation language).

I am not in agreement however that CTI Common should be a separate work product (as on the ballot).

Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

Inactive hide details for Paul Patrick ---03/17/2016 01:43:42 PM---+1 on the comments both by Sean and Jeff.   Paul PatrickPaul Patrick ---03/17/2016 01:43:42 PM---+1 on the comments both by Sean and Jeff. Paul Patrick

From: Paul Patrick <ppatrick@isightpartners.com>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 03/17/2016 01:43 PM
Subject: Re: [cti] RE: Some additional thoughts on combining STIX and CybOX
Sent by: <cti@lists.oasis-open.org>

+1 on the comments both by Sean and Jeff.  

Paul Patrick

On 3/17/16, 10:58 AM, "Mates, Jeffrey CIV DC3/DCCI" <cti@lists.oasis-open.org on behalf of Jeffrey.Mates@dc3.mil> wrote:

>I'm strongly in favor of keeping the two separate.  Having separate documents makes it easier to deal with when switching between writing tools that deal with threat actor attribution instead of crimes that merely happen to involve computers.
>Jeffrey Mates, Civ DC3/DCCI
>Computer Scientist
>Defense Cyber Crime Institute
>-----Original Message-----
>From: cti@lists.oasis-open.org [
mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
>Sent: Thursday, March 17, 2016 10:52 AM
>To: cti@lists.oasis-open.org
>Subject: [Non-DoD Source] [cti] Some additional thoughts on combining STIX and CybOX
>Several people have suggested that it would be more convenient to combine STIX and Cybox, characterizing it as a documentation issue where it would be easier to read a single document.
>Several people have explicitly stated that it is important technically that CybOX remain a separate standard to support diverse domain standards like STIX, MAEC, DFAX, etc in a focused and unbiased manner. They have also pointed out that it is a standards issue (different development groups/opinions, different conformance and different referencing) not simply a documentation issue.
>Sean’s opinion:
>There are a lot of technical details that have been provided by numerous members of the community why STIX and CybOX should not be combined. I will not restate those here. Rather, I would just add to those details a simple statement on our responsibilities as a standards body.
>As a TC that took on responsibility for the maintenance and ongoing development of CybOX as an independent standards effort (specifically called out as such in the TC charter) we have a responsibility to continue to respect the purpose for CybOX and the community of efforts and players (including several within the TC) that depend on it as a separate standard focused on the facts of cyber observables.
>Does the TC technically have the authority to ignore the needs of this community of players and efforts and change CybOX into whatever it feels like? Yes.
>Is that a responsible or appropriate course of action? In my opinion, definitely not.
>In my opinion, it is not an appropriate standards decision to place personal opinions of convenience in form factor over directly expressed technical needs of the community.
>Thank you for considering my opinions.


Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

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