OASIS Open Command and Control (OpenC2) TC

All, The purpose of this email is to solicit potential use cases and participants for the pending Plug Fest. Recall that USCYBERCOM will host a Plug Fest for OpenC2 in January 2020 at the DreamPort facility located in Columbia Maryland. On the first week of November (exact date to be determined) we will provide a 'Tech Talk' where we will present OpenC2 and talk about the pending Plug Fest. The Plug Fest itself will take place over two days and will be on the week of January 21 or January 27 (exact dates to be determined). I took the liberty of attaching a slide deck that outlines a use case of interest to the US Department of Defense. The slide deck also has a list of the actuator profiles efforts that are underway. I have four requests of you. ONE: Provide use cases of interest to you that we could work at the OpenC2 Plug Fest TWO: In the context of your products, create an OpenC2 'Proxy' or 'Shim' so that your product can address the use cases THREE: Identify what you need to have provided by the DreamPort facility (such as internet connectivity, rack space, power requirements etc) FOUR: If you have experience with other Plug Fests, consider helping to organize and coordinate this effort. Thank you Very Respectfully Joe Brule Engineering (Y2D122) FNX-3, B4A335 410.854.4045 'Adnius ad retinedam puritem noster peciosus corporalis fluidorum...' I welcome VSRE emails. Learn more at http://vsre.info/ Attachment: DRAFT_PlugFest1_Use_case.PPTX Description: DRAFT_PlugFest1_Use_case.PPTX

All,   I received two additional use cases to consider for the pending Plug Fest:  USE CASE A: Courtesy of a colleague who is a member of the Trusted Computing Group, An orchestrator receives notification that a new device has joined the network. It instructs an actuator to determine the devices' compliance to network policy. The actuator requests a SWID formatted software inventory from the device, The software inventory is compared to network policy. The actuator then determines whether to sandbox the device, remove it from the network, or allow it network access based on the result of the comparison. The orchestrator informs an actuator that a critical vulnerability needs to be patched. The actuator checks the Configuration Management Database for device running the vulnerable software. The actuator ensures that these devices receive the required patch.   USE CASE B:  Courtesy of a colleague employed by an intelligent systems company “Here’s one off the cuff: A firm’s SOC becomes aware that an ATP group is campaigning against similar enterprises to itself. A command is issued to the firm’s organizational units to Monitor and Hunt for evidence of that ATP’s TTPs in their networks. One of the units reports TTP indicators are found. The threat intelligence from that unit is Reported to the other units. A command is issued to Isolate the effected unit’s subnet from the others. A command is issued to stand up honeypots at potential lateral movement locations at the effected and adjacent units. There are hundreds of use cases….”   For Use Case A, I see An alert that is beyond the scope of OpenC2 A ‘contain’ action on a ‘device’ target that limits the new devices permissions An ‘investigate’ action on a ‘device’ target A ‘query ‘ action and we will need to import a target to accommodate SW inventory A ‘scan’ action on a target to accommodate SW inventory which will compare the inventory to the network policy An analytic that is beyond the scope of OpenC2 An ‘allow’ action on a device A ‘deny’ action on a device target A ‘contain’ action on a device target An ‘update’ action on a target we will need to import to accommodate a software target   I could do a similar exercise for Use Case B, but I am quite confident that different subject matter experts will approach these use cases in different ways and acknowledge that what I saw for Use Case A is at best sub-optimal (and probably flat our wrong).    May I propose that we continue to collect use cases and over the course of the next several weeks and we have weekly meetings?  The purpose of the meetings is to refine the action/Target pairs and flesh out the functions we will need to realize the use cases.    Sound logical?  If not, will you provide an alternative way forward?    Thank you   VR   Joe Brule    
Original Message----- From: Brule, Joseph M Sent: Wednesday, September 25, 2019 12:57 PM To: openc2@lists.oasis-open.org Subject: OpenC2 Plug Fest: Need Use Cases, OpenC2 Producers and OpenC2 Consumers   All,   The purpose of this email is to solicit potential use cases and participants for the pending Plug Fest.  Recall that USCYBERCOM will host a Plug Fest for OpenC2 in January 2020 at the DreamPort facility located in Columbia Maryland.    On the first week of November (exact date to be determined) we will provide a 'Tech Talk' where we will present OpenC2 and talk about the pending Plug Fest.  The Plug Fest itself will take place over two days and will be on the week of January 21 or January 27 (exact dates to be determined). I took the liberty of attaching a slide deck that outlines a use case of interest to the US Department of Defense.  The slide deck also has a list of the actuator profiles efforts that are underway.  I have four requests of you. ONE:  Provide use cases of interest to you that we could work at the OpenC2 Plug Fest TWO:  In the context of your products, create an OpenC2 'Proxy' or 'Shim' so that your product can address the use cases THREE:  Identify what you need to have provided by the DreamPort facility (such as internet connectivity, rack space, power requirements etc) FOUR:  If you have experience with other Plug Fests, consider helping to organize and coordinate this effort.   Thank you   Very Respectfully   Joe Brule Engineering (Y2D122) FNX-3, B4A335 410.854.4045 'Adnius ad retinedam puritem noster peciosus corporalis fluidorum…' I welcome VSRE emails.  Learn more at http://vsre.info/