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?|
VOTING CLOSED: Monday, 21 March 2016 @ 12:00 pm EDT
|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|
|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%|
|Options with highest number of votes are bold|
|Option||# Votes||% of Total|
|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|
|Angel, Mark||U.S. Bank||--|
|Asok Kumar, Aishwarya||Soltra||--|
|Baker, Jonathan||Mitre Corporation||--|
|Burger, Eric||Georgetown University||--|
|Butts, Brad||U.S. Bank||--|
|Casanave, Cory||Object Management Group||--|
|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.||--|
|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||--|
|Moss, Mark||Johns Hopkins University Applied Physics L...||--|
|O'Brien, Chris||United Kingdom Cabinet Office||--|
|Sander, Tomas||Hewlett Packard Enterprise (HPE)||--|
|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...||--|
|Taylor, Chris||United Kingdom Cabinet Office||--|
|Verma, Jyoti||Cisco Systems||--|
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.
|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??
|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.
|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.
|No||No. There should be two standards, and two work products (STIX and CybOX, but no shared CTI Common document.
|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.
DHS Office of Cybersecurity and Communicat...
|No||I have the same questions as Mark Davidson's comments.
Mainly the 'Why's #5 and #6.
|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.
|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?
|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.
Blue Coat Systems, Inc.
|No||Same comment as Mark
|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.
|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...
|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.