RE: Scope of OpenC2

["Brule, Joseph M" <jmbrule@radium.ncsc.mil>]

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:

1. 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.

2. 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

3. 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