Comments on Motion for Ballot on Scope of OpenC2

I (Duncan speaking as sFractal Consulting, not as a co-chair) perceive one of the root issues underlying alot of these questions is OpenC2 applicability to for use in STIX Course of Action and what is this TC's role, what is CTI TC role, and is there a gap. I'm basing this on the timing of Bret's email wrt my CTI email questioning Bret's assertion on the CTI mailing list that OpenC2 may not be the applicable for C2 in STIX. I agree with him that answering the questions below certain ways could preclude OpenC2 from being used as the STIX C2. Therefore I think the use cases should be included in the discussion since what is applicable in one use case may not be in another and we shouldn't talk past each other. I think the use of OpenC2 for STIX should specifically be part of the discussion so we don't inadvertently preclude OpenC2 from being used and cause an almost identical parallel effort to be set up.

I would also propose the wording of 2.1.1 be changed from "If everyone can do their own things with transport then no one will be interoperable" to something less pejorative like "Should OpenC2 be transport agnostic or should we have mandatory (or recommended) transport alternatives; and if so how many and which ones?".

Is the proposal to have one ballot (yeah or nay to a to-be-developed set of answers to these questions) or each question as it's own ballot? If it is to be one question, should it instead be 'Should OpenC2 scope include what is necessary for use in STIX COA?' since that appears to be fundamental factor in the disagreements?

sFractal Consulting LLC

iPhone, iTypo, iApologize

-------- Original Message --------
Subject: [openc2] Scope of OpenC2
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Fri, September 22, 2017 1:02 pm
To: "openc2@lists.oasis-open.org" <openc2@lists.oasis-open.org>

TC,

Over the past few weeks we have had some lively discussions on Slack. A lot of the debates come down to scope of what should and should not be done / defined in OpenC2. Some of this relates to interoperability, some of it relates to functionality.

I MOTION that we have a discussion at the TC level about scope and functionality and then have a ballot on it to decide.

Areas I would like discussed:

What is an OpenC2 command...
1. Is it a single atomic command or can it contain multiple commands
2. Is it limited to just automatable commands or can it contain human process commands
3. Is the destination known ahead of time, meaning this command is being sent to Cisco ASA 4.2, or can it be destined to any.
  1. Example, is it a unicast session, multi-cast, or broadcast, or sessions
  2. How do we hand targeting for broadcast/multi-cast sessions
    1. The targeting we have now is for the thing on the device, but how do you target the device as a whole
    2. Send command to all systems and only have Windows 10 Sp1 systems pick it up no Windows 8 systems
4. Should we allow commands other than OpenC2 commands, like bash or powershell commands
5. How do we deal with multiple commands, the sequencing of those commands and any temporal / conditional logic around them.
How do we deal with interoperability
1. What features and functions MUST be MTI (mandatory to implement)
2. How to we handle transport
  1. If everyone can do their own things with transport then no one will be interoperable
3. What kind of tests / unit tests do we need to create to make sure products can talk to each other
4. How to we ensure the brand of "openc2" does not get diluted
5. How do we deal with authentication and encryption
  1. Do we define MTI features
  2. Or do we define a negotiation protocol
Should the OpenC2 commands have IDs that would enable them to be connected to a graph data model
1. How should these commands be tied together to form a playbook
2. How should they be linked to CTI threat intel in a TIP

If the OpenC2 TC decides that most of this is out of scope after a ballot then I will propose that a new TC be formed to tackle this higher level stuff.

Bret

openc2 message