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