oasis-tcs / openc2-usecases Goto Github PK

The plugfest/hackathon has limited time so we should be efficient and work out ahead of time what to do.
I see a tradeoff between two worthwhile objectives. One objective is to test interoperability between different implementations. This tests each implementation as well as discovers clarifications
needed in the OpenC2 specifications. A different objective is to demonstrate use case scenarios.

One example showing the different approaches would be the following use case: Prod1 is an orchestrator with OpenC2 producer capability. Cons2 is an IoT actuator with OpenC2 consumer capability. The user has the following policy for new devices entering their network based on reviewing the SBoM of the new device:

• if any software components have a pedigree/provenance to DPRK - sandbox the device is a special deception center to analyze
• if any software components have known malware - sandbox the device in a malware detonator for analysis
• if any software components have CVE's with CVSS >3 - install the device in an update DMZ and perform software updated before restarting this process
• if any software components are on a user watch list - install the device in normal network with increased firewall/ids/etc logging
• otherwise install the device normally
  The set of use case scenarios is adding Cons2 to Prod1 network exercising the various legs of the policy.

Both the 'just test the commands' approach and the 'demonstrate the use case' approach involve creating scenarios of the different cases and analyzing the OpenC2 commands and responses. In the former, the scenarios inform the commands to test. In the latter, you actually exercise the decision tree.

In the 'just test the commands' approach you might send just one 'get SBoM' command and validate you can get a response. Then totally independently you might send a 'increase logging on firewall for this device' command. And independent of that you might send ...
In the 'demonstrate the use case' approach you would 'test' the orchestrator decision logic as well.
First you might send a 'get SBoM' command and arrange for the returned SBoM to appear to have software from North Korea, and then validate the orchestor did the correct followup actions.
Then you might send a 'get SBoM' command again and arrange for the returned SBoM to appear to contain known malware ...

IMHO the 'demonstrate the use case' approach requires more work in many cases than the 'just test the commands' approach. I am not against demonstrating, particularly when it's easy and efficient.
I advocate more focus on the 'just test the commands' approach to make the most use of our time. I maintain that if the commands work, logical people can infer the use case scenarios will work.

FAQ's (https://github.com/oasis-tcs/openc2-usecases/tree/master/Cybercom-Plugfest#63-faq) on networking need answering:

• Will WiFi be provided? More than one SSID? What networking details?
• Will wired ethernet be provided? More than one network? What networking details?
• DHCP or Static IP or choice-of-either? Will IP addresses (or at least ranges) be available prior to arriving to allow preconfiguration (eg only allow access from these ranges)
• IPV4? IPV6?
• Will our devices be able to reach the internet? Will ip's/ports need to be prearranged to get thru firewalls?
• Will our devices be reachable from the internet? Will ip's/ports need to be prearranged to get thru firewalls?

FAQ's (https://github.com/oasis-tcs/openc2-usecases/tree/master/Cybercom-Plugfest#63-faq) on collaboration need answering:

• Will whiteboards be provided?
• Will projector be provided?

1. IMO the difference among contain / allow / deny WRT to a device is that contain would be used to establish a limited scope of network access (e.g., put the new endpoint on a VLAN for S/W updates and vulnerability remediation), whereas deny would isolate the device and allow would grant access to whatever range of network operations is "normal" for that device.

2. For purposes of a plug-fest use case, I would just assume the Network Manager "knows" the policy. Where it comes from in an operational setting can be worked out at another time. Ideally we'd want to demonstrate scenarios of:
   • clean device: contain, query, allow
   • clean-able device: contain, query, update, allow
   • failed device: contain, query, deny

3. In the first set of network functions, it seems to me that the investigate from NM Producer to EM Consumer is all that's needed. I don't see the point in the subsequent query. I do think the investigate command might need both an immediate response ('I'm on it.") and a completion response: ("device allowed / remediated / denied.").

I've also posted these comment in the Slack channel for the plug fest: https://openc2-community.slack.com/archives/CNW18R2NR/p1570205787004200