Ballot Details: CTI Common Proposal (CLOSED)

Ballot Question Should we separate out common STIX / CybOX constructs into a new CTI TC work product called CTI Common?
Ballot Description Whereas there are significant interdependencies (timestamps, relationships, TLO identifiers, versioning constructs, etc) between the STIX and CybOX standards, whereas there is consensus within the TC as to the criticality of ensuring that these cross-cutting constructs be kept in sync between the two standards, do you agree with the CTI TC resolving that CTI Common will be an official CTI TC work product, under the joint oversight of the STIX and CybOX SCs?
Ballot Options
VOTING CLOSED: Monday, 21 March 2016 @ 12:00 pm EDT
Yes 9 32.143
No 19 67.857
Abstain 2
Open Date Monday, 14 March 2016 @ 12:00 pm EDT
Close Date Monday, 21 March 2016 @ 12:00 pm EDT
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 28
Eligible members who have voted 30 of 67 44.776%
Eligible members who have not voted 37 of 67 55.224%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 9 32.143%
No 19 67.857%
Abstain 2

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Barnum, Sean Mitre Corporation Yes 2016-03-15 17:13:00 1
* Foley, Alexander Bank of America Yes 2016-03-14 16:08:00
* Maroney, Patrick Integrated Networking Technologies, Inc. Yes 2016-03-16 17:21:00
* Masuoka, Ryusuke Fujitsu Limited Yes 2016-03-17 03:24:00
* Patrick, Paul iSIGHT Partners, Inc. Yes 2016-03-15 14:26:00 1
* Peloquin, Joey Citrix Systems Yes 2016-03-14 16:29:00
* Piazza, Richard Mitre Corporation Yes 2016-03-15 17:44:00 1
* Pumo, Beth Kaiser Permanente Yes 2016-03-16 15:36:00
* Rutkowski, Anthony Yaana Technologies, LLC Yes 2016-03-17 00:24:00
* Anderson, Denise National Council of ISACs (NCI) No 2016-03-18 21:52:00
* Baikalov, Igor Securonix No 2016-03-16 18:03:00
* Brown, Iain United Kingdom Cabinet Office No 2016-03-16 11:24:00
* Chernin, Aharon Soltra No 2016-03-14 17:00:00 1
* Clancy, Mark Soltra No 2016-03-14 21:57:00
* Coderre, Robert VeriSign No 2016-03-14 18:16:00 1
* Davidson, Mark Soltra No 2016-03-14 16:36:00 1
* DePeppe, Doug Cyber Threat Intelligence Network, Inc. (C... No 2016-03-21 13:36:00
* Jordan, Bret Blue Coat Systems, Inc. No 2016-03-14 16:50:00 1
* Katz, Gary US Department of Defense (DoD) No 2016-03-14 18:26:00
* Keirstead, Jason IBM No 2016-03-15 15:22:00 1
* Kelley, Sarah Center for Internet Security (CIS) No 2016-03-16 14:32:00
* Khan, Ali Soltra No 2016-03-14 17:24:00
* MacDonald, Terry Soltra No 2016-03-18 19:51:00 1
* Maxwell, Kyle VeriSign No 2016-03-18 17:40:00 1
* Riedel, Daniel New Context Services, Inc. No 2016-03-17 15:15:00
* Taylor, Marlon DHS Office of Cybersecurity and Communicat... No 2016-03-17 16:15:00 1
* Thompson, Dean Australia and New Zealand Banking Group (A... No 2016-03-19 14:38:00
* Wunder, John Mitre Corporation No 2016-03-17 15:53:00 1
* Darley, Trey Soltra Abstain 2016-03-21 10:24:00 1
* Jones, Elysa Individual Abstain 2016-03-21 13:38:00 1
* Allor, Peter IBM --
* Angel, Mark U.S. Bank --
* Asok Kumar, Aishwarya Soltra --
* Athias, Jerome Individual --
* Baker, Jonathan Mitre Corporation --
* Burger, Eric Georgetown University --
* Butt, Michael Soltra --
* Butts, Brad U.S. Bank --
* Casanave, Cory Object Management Group --
* Clark, Peter IBM --
* Dye, Daniel Soltra --
* Eilken, David Financial Services Information Sharing and... --
* Figueroa, Wilson ViaSat, Inc. --
* Ginn, Jane Cyber Threat Intelligence Network, Inc. (C... --
* Gurney, John-Mark New Context Services, Inc. --
* Huang, Wei Anomali --
* Hundley, Gordon DTCC --
* Kakumaru, Takahiro NEC Corporation --
* Kirillov, Ivan Mitre Corporation --
* Landfield, Kent Intel Corporation --
* Laurance, David JPMorgan Chase Bank, N.A. --
* Magathan, Mona U.S. Bank --
* McLellan, Mike United Kingdom Cabinet Office --
* Morris, John IBM --
* Moss, Mark Johns Hopkins University Applied Physics L... --
* O'Brien, Chris United Kingdom Cabinet Office --
* Sander, Tomas Hewlett Packard Enterprise (HPE) --
* Sharda, Ravi EMC --
* Smith, Pamela Johns Hopkins University Applied Physics L... --
* Stekervetz, Justin US Department of Homeland Security --
* Storms, Andrew New Context Services, Inc. --
* Struse, Richard DHS Office of Cybersecurity and Communicat... --
* Suarez, Natalie Soltra --
* Taylor, Chris United Kingdom Cabinet Office --
* Verma, Jyoti Cisco Systems --
* Williams, Jeff Dell --
* Williams, Ron IBM --

Voter Comments

Submitter Vote Comment
Patrick, Paul
iSIGHT Partners, Inc.
Yes Because CTI Common has a life outside of STIX 2.0, it should be kept separate. This is not different from other OASIS efforts that have occurred in the past where a component of one is leveraged by others.
Piazza, Richard
Mitre Corporation
Yes Well, so far, it is an unofficial work product - in other words, we are handling it as a separate document.

Currently it contains:

IDs, markings, vocabularies (controlled and extended), timestamps, cti-core, descriptive-properties and relationships.

All of these apply equally to STIX and CybOX.

As stated, why document this in two places??
Barnum, Sean
Mitre Corporation
Yes I just wanted to provide a clarification for those who may be confused.

A "work product" in OASIS just means a separate document managed by the TC (exactly what we are doing now).

There is no requirement whatsoever that such a document ever be put forward as a separate standard.
Coderre, Robert
VeriSign
No I echo Aharon's comments. These definitely need to be developed in synch, but as written, it's not clear how a separate document / work process is maintained going forward.
MacDonald, Terry
Soltra
No No. There should be two standards, and two work products (STIX and CybOX, but no shared CTI Common document.
Maxwell, Kyle
VeriSign
No Based on the clarifications from OASIS on the differences between documents, work products, specifications, standards, etc., I'm not sure I see the need for a specific "work product". A coordinated / shared "document" may be a better choice, because the need for *something* definitely exists.
Taylor, Marlon
DHS Office of Cybersecurity and Communicat...
No I have the same questions as Mark Davidson's comments.

Mainly the 'Why's #5 and #6.
Keirstead, Jason
IBM
No I am voting No along the same lines as Mark. I also agree with Aharon that I support the idea of a separate SC for the common aspects.

Just because we have a separate SC does not mean it has to create a separate work product.
Chernin, Aharon
Soltra
No I do support the creation of a subcommittee to work on the common items between STIX and CybOX, as well as the common elements between STIX high level objects. However, there are to many questions based on how the ballot is worded:

*) What the heck is this standard called? With STIX / TAXII we have well, STIX and TAXII. Now we will have a new standard called Common?
*) Is adding a fourth standard going to make STIX / TAXII / CybOX easier to understand and implement?
Wunder, John
Mitre Corporation
No I agree w/ Mark Davidson's comments.

In particular, regarding #6, I think there's some latitude to consider how external specifications will reference CybOX and whether we can't have a better division than we have now. Some of those changes may open us to a simpler approach that doesn't require the separate CTI Common layer, so I don't think we should just press forward with what we have without thinking about that more.

I also strongly agree with Mark's points #1, #3, and #5 (users = users of STIX as well as other specifications referencing STIX/CybOX).

I'm working on a proposal for this and hope to have it available by 18 March. For the record, it DOES maintain a separation of STIX and CybOX.
Jordan, Bret
Blue Coat Systems, Inc.
No Same comment as Mark
Davidson, Mark
Soltra
No I will be voting no on the resolution as phrased. My position on CTI Common is that we currently don’t have enough information to know whether it should be a standards-track work product. I am 100% on board with keeping the document and continuing work on it (i.e., what we have been doing) as a way to help answer these questions. My no vote does not constitute a vote to destroy the document/concept. I will list my open questions below, and I will change my vote if they can be answered sufficiently.

My open questions are:

1. What will the CTI Common conformance clauses look like? OASIS specifications are required to have a conformance section, and each specification we produce must be meaningful enough to stand on it’s own.

2. What types of software will claim conformance to CTI Common on it’s own?

3. Is there a solution to the STIX->CTI Common->CybOX cyclic dependency that I have raised?
1. Any change to STIX that impacts CTI Common will essentially force a revision to CybOX.

4. How will the overall “STIX” conformance clause be phrased? Implementers want to say they are “STIX 2.0 conformant”. Will it be “STIX 2.0 means CTI Common 1.0, STIX 2.0, CybOX 3.0”?

5. Why do downstream users of our work require this separation?
1. We have heard the “what" (that a separate document is desired) from some, but I haven’t seen “why” clearly articulated. Since downstream users are being used as a reason for this separation, the group deserves the “why” to be clearly articulated.

6. Why do Observations (nee Observables) need a different treatment from other STIX Top Level Objects (relationships, indicators, etc). I realize there is historic precedence for CybOX being separate, but this group has the power to re-evaluate whether that historic separation still makes sense.

I will reiterate that these open questions are reasons to keep working on CTI Common – to help answer them. However, for me and at this time, they are the reasons that I cannot definitively say that I think CTI Common should become it’s own work product and they are the reasons I will be voting no. That said, we have a two week discussion period and I am open to changing my vote.

Thank you.
-Mark
Darley, Trey
Soltra
Abstain Since before the CTI TC was established, I have been concerned that STIX and CybOX would get out of sync under separate committees, due to human politics and Murphy's Law. As it was abundantly clear that the notion of merging the two standards under a single committee would get no traction, I proposed CTI Common as a plan B at the Tampa F2F.

As the TC readily embraced CTI Common and everybody was happily working away at it for the past three months, this ballot struck me as the most inane administrivia imaginable. It seemed to me at the time that there was overwhelming consensus that the CTI Common was the best approach to keeping STIX and CybOX in lockstep. This ballot measure was simply intended to somewhat formalize CTI Common, such that a newcomer to the TC would have a clue what we were talking about.

Never in a thousand years did I imagine that this ballot would kick off so much discussion and controversy. Clearly I was wrong.

Time for plan C...
Jones, Elysa
Individual
Abstain My first inclination was the common work should be pulled together to avoid confusion and duplication. This doesn't mean a specific and separate work product is required but the human work should be undertaken and reviewed in a common subcommittee. It can be decided later where it is best appropriate to capture this in the OASIS work product sense. Given the comments, I chose to abstain at this point as the decision is premature, IMHO.