OASIS Open Command and Control (OpenC2) TC

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...  Is it a single atomic command or can it contain multiple commands Is it limited to just automat able commands or can it contain human process commands 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. Example, is it a unicast session, multi-cast, or broadcast, or sessions How do we hand targeting for broadcast/multi-cast sessions The targeting we have now is for the thing on the device, but how do you target the device as a whole Send command to all systems and only have Windows 10 Sp1 systems pick it up no Windows 8 systems Should we allow commands other than OpenC2 commands, like bash or powershell commands 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 What features and functions MUST be MTI (mandatory to implement) How to we handle transport If everyone can do their own things with transport then no one will be interoperable What kind of tests / unit tests do we need to create to make sure products can talk to each other How to we ensure the brand of "openc2" does not get diluted How do we deal with authentication and encryption Do we define MTI features 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 How should these commands be tied together to form a playbook 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

Bret,   You are free to make this motion at the next TC meeting which will take place on October 18 at 11:00 and 21:00 Eastern.    All,   This is an atypical means of announcing a topic for the next monthly business meeting, but as an FYI.   VR   Joe Brule Co-chair OpenC2 Technical Committee       From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org] On Behalf Of Bret Jordan Sent: Friday, September 22, 2017 1:03 PM To: openc2@lists.oasis-open.org Subject: [Non-DoD Source] [openc2] Scope of OpenC2   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...  Is it a single atomic command or can it contain multiple commands Is it limited to just automatable commands or can it contain human process commands 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. Example, is it a unicast session, multi-cast, or broadcast, or sessions How do we hand targeting for broadcast/multi-cast sessions The targeting we have now is for the thing on the device, but how do you target the device as a whole Send command to all systems and only have Windows 10 Sp1 systems pick it up no Windows 8 systems Should we allow commands other than OpenC2 commands, like bash or powershell commands 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 What features and functions MUST be MTI (mandatory to implement) How to we handle transport If everyone can do their own things with transport then no one will be interoperable What kind of tests / unit tests do we need to create to make sure products can talk to each other How to we ensure the brand of "openc2" does not get diluted How do we deal with authentication and encryption Do we define MTI features 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 How should these commands be tied together to form a playbook 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  

As stated, the question is ill-formed.   The OpenC2 TC has three subcommittees – Language, Profiles, and Implementation.   Each of those SCs has a set of documents on their roadmap.   There shouldn’t be much disagreement on “what should and should not be done/defined in OpenC2”.   The lively discussion on Slack concerns “what should be defined in the OpenC2 Language Spec” and “what should be defined in the Implementation specifications”.   When the question is framed in terms of scope of the subcommittee specifications, it will be ready to be debated and voted.   Dave   From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org] On Behalf Of Bret Jordan Sent: Friday, September 22, 2017 1:03 PM To: openc2@lists.oasis-open.org Subject: [Non-DoD Source] [openc2] Scope of OpenC2   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...  Is it a single atomic command or can it contain multiple commands Is it limited to just automatable commands or can it contain human process commands 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. Example, is it a unicast session, multi-cast, or broadcast, or sessions How do we hand targeting for broadcast/multi-cast sessions The targeting we have now is for the thing on the device, but how do you target the device as a whole Send command to all systems and only have Windows 10 Sp1 systems pick it up no Windows 8 systems Should we allow commands other than OpenC2 commands, like bash or powershell commands 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 What features and functions MUST be MTI (mandatory to implement) How to we handle transport If everyone can do their own things with transport then no one will be interoperable What kind of tests / unit tests do we need to create to make sure products can talk to each other How to we ensure the brand of "openc2" does not get diluted How do we deal with authentication and encryption Do we define MTI features 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 How should these commands be tied together to form a playbook 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