The thread started with a proposed line between playbooks and atomic commands. None of this is inconsistent with your examples (âlock the doors and draw the blindsâ).
If a playbook is informally understood to be a collection of operations, it behooves both TCs to have a rigorous understanding of what comprises an âoperationâ.
-------------- Tuesday, September 24, 2019 10:10 AM -----------------------
Iâd suggest that our scope is: - Atomic actions. Those actions may involve multiple actuators and multiple operations within a particular actuator, but as the word âtransactionâ implies, they succeed or fail as a unit. An atomic action to âtransfer money from one bank account to anotherâ requires that money removed from one account appear in another, otherwise the integrity of the transaction is violated. A command to âblock this IP address at the perimeterâ may involve 100 perimeter actuators, and if the semantics of the action is to result in a secure perimeter, then 99 successes and 1 failure results in a failure of the atomic action. If the semantics of the action is âupdate file to the latest versionâ, and 50 actuators already have the latest version then 50 file updates and 50 do-nothings is a successful atomic action.
If there is conditional logic that involves taking some action depending on the status of some other action (including the mechanics of enforcing transaction integrity), that is out of scope for the content of OpenC2 commands. - Command and Control of any cyber defense function â C2 for sensors, C2 for analytics, C2 for decisionmaking (the only example I can think of is âinstall this policyâ) is in scope. Performing sensing and analysis and decisionmaking, after the policies have been configured, is out of scope.
- M2M, M2H, H2M are in scope if they involve C2, and not in scope if they involve performing sensing and analysis and decisionmaking operations other than control. A command to âBlock IP Addressâ is in scope even if the actuator puts up an alert on a userâs phone or browser or queues a ticket in a database. A decision to âExecute Plan Aâ may come into a Producer from another Producer or from a human producer agent â if it makes sense to have an OpenC2 command to perform that function M2M, then the identical command can be executed H2M. Input (other than control inputs) to analytics and decisionmaking is always out of scope, whether the recipient is H or M.
Just my 0.02. Dave Dragging conversation into the open. If CACAO believes they are the Playbook, we should certainly make every effort to be able to run CACAO plays with OpenC2. What matters, though, is their charter, and what their members want to do. In a principle similar to that in play when One Congress cannot limit what the next session of Congress may or may not do, an OASIS TC cannot declare boundaries for or material off base to another OASIS TC. It is not unknown for the work products of two TCs to be competitive, and the use in a particular sphere is then fought out in the market. This is a different question than whether OpenC2 may send two commands in the same message. We may wish to request a device to Lock the Doors and Draw the Curtains as two simultaneous commands, or to quarantine files that look like this and shred devices that look like that. When we add telemetry requests (if we do), we may want to log several kinds of activity. We may wish to send a stateless and a stateful PF request in the same message. We may even want to send two commands in a single message AS directed by a CACAO playbook. We should not cripple OpenC2 on the off-chance that it may be able to combine well with CACAO. tc As Duncan said, we've moved from procedure to content and I'd agree the content should be shared with the L-SC or maybe even the TC, since it's speaks to the overall scope of OpenC2. I'm very comfortable with the way that DaveK has described the scope of M2M for OpenC2: where it incidentally can be used to support M2H interactions that's great, but it's not a requirement. I also think H2M is completely outside the scope of OpenC2. Where something happens because of an H2M interaction, that's an implementation decision that doesn't affect the content of the M2M interaction that presumably follows, and that content is our focus. I do think the CACAO TC needs to be very strongly encouraged to bring unsupported use cases to OpenC2 for consideration, and we should accept or reject them along the lines that DaveK has described so well. David P. Lemire, CISSP HII Mission Driven Innovative Solutions (HII-MDIS, formerly G2, Inc.) Technical Solutions (A Division of Huntington Ingalls Industries) Started as a procedural discussion so appropriate. Now itâs beyond that and you are correct iPhone, iTypo, iApologize
From: Brule, Joseph M < jmbrule@radium.ncsc.mil> Sent: Tuesday, September 24, 2019 4:51 PM To: 'David Kemp'; 'Vasileios Mavroeidis'; duncan sfractal.comCc: dave.lemire; OpenC2CoChairs Subject: RE: Action Item: OpenC2 "Liaison" with CACAO Is there any reason why this email thread is not being sent to the Language SC email distribution? Not a âcontroversyâ, but there are legitimate points of discussion â Tools for editing schemas SHOULD support displaying and editing this keyword. â Implementations MAY strip "$comment" values at any point during processing. That section in its entirety is so perfect that I copied it into JADN requirements.
> It has always been my assumption that the future of cyber defense would be automated actions occurring in cyber relevant time. When we are scoping OpenC2, the requirements we need to address are to support M2M actions occurring in cyber relevant time. But as we design to satisfy M2M requirements, we shouldnât go out of our way to prevent them from enabling H2M and M2H interactions.
Case in point: OpenC2-Response was designed to contain a âstatus-textâ field; we attempted to describe it the way JSON Schema describes $comment. We could go further and say âimplementations MAY strip status_text at any point during processingâ, and when doing so MUST achieve the identical results as if status_text didnât exist at all.
So when we get down to the nitty-gritty of deciding what is in scope and out of scope for OpenC2, our *requirements* must come from M2M use cases, but if there opportunities to also satisfy H2M and M2H without breaking M2M, then we can consider them just as we did with status_text. If CACAO says âHereâs a M2H requirement that OpenC2 doesnât satisfyâ, and it isnât related to a M2M requirement, then I think OpenC2 is justified in rejecting it as out of scope. So for human actuators, a Consumer that takes an M2M command and produces a phone alert is in-scope for existing M2M actuator profiles. Creating a M2H profile that addresses general usage of phone alerts not related to M2M actuators is out of scope. Human interactions that are incidental to M2M design is fine; human interactions that go beyond M2M design are not. Dave When I read this, it sounds logical so I am not seeing what the issue is. - Nothing in this email impacts the language specification (define the actions, the semantics, the syntax â.)
- Nothing in this email impacts the actuator profiles (puts the language in the context of the cyber defense function, tailors the actions, augments with arguments and/or targets if needed)
- This could impact the transfer specs. The need to support an array of DENY ip_net commands could be done via a publish a topic that a bunch of actuators subscribe to (think MQTT or OpenDXL), use of multicast (multiple RFCâs but 5110 comes to mind), define a message type in an annex in the HTTPS spec etc.
The fact that the CACOA TC is drafting their spec to be agnostic of the language used to express actions is logical. They should be agnostic of OpenC2 and OpenC2 should be agnostic of any business process management language. If CACOA has a bunch of use cases that OpenC2 cannot support, then it behooves us to get it in version 1.1. If our efforts do not support CACOA, then we do have the hooks in place extend the language with arguments and/or targets. It has always been my assumption that the future of cyber defense would be automated actions occurring in cyber relevant time. Normally, carbon based life forms are not fast enough to respond in milliseconds. OK, that was a little snarky, and if COCOA is concerned because we cannot support humans, then what is to stop us from creating an actuator profile? I will ack that when I think actuators, I think silicon based, not blobs of protoplasm however does the language specification preclude the drafting of an actuator profile? What is the controversy? Duncan, Dave, OpenC2 is atomic actions. âCompoundâ actions could be supported in a very simplistic manner. The simplest form is an array of non-coordinated actions. That is for example an array of OpenC2 deny actions with target domain names. So related in terms of context, lets say blocking the communications with C2s of a specific malware. - This is pretty useful if we take into account the security operations of today. Dave supports OpenC2, I support OpenC2 and I want to send Dave an OpenC2 action array for a specific malware. Now if we want this to be coordinated when the targets are many (more than one) and not one we would have to implement some kind of logic in our infrastructure. Not OpenC2 related. We donât want that. Its good to have this simple capability for people that donât want to mess with CACAO but still want to send multiple commands. For a unique type of target per array I donât see any possible difficulties in the implementation.
- This also supports the M2M communication. A sandbox wants to issue a command to a firewall for blocking the above domains after analysis. If this happens in real-time (I guess it wonât be the case) then the sandbox is supposed to issue atomic OpenC2 command to the firewall. If its after analysis an array of all domains would be more logical to happen.
I just read Daveâs Kemp email while writing this one. Point 3. Is great explanation. Regarding CACAO now: Until now the consensus is that CACAO should be action-language independent. I do agree with that. A playbook though when created should define the namespace of the language used for atomic actions (aka OpenC2 or..). I think OpenC2 will be the standard action language at the end of the day (I donât even know if we have other candidates or as I believe some may want to develop a new taxonomy of targets etc.). In any case this should not be priority since we have OpenC2 that can support CACAO right now and for sure we can enrich it based on the CACAO use cases. We can focus putting our efforts in developing the appropriate language and schema to support logic. This is what im going to propose in the next meeting. I also have a slide that im going to publish to the CACAO community soon. Vasileios Mavroeidis â Security Researcher and Ph.D. Research Fellow
Research Group of Information and Cyber Security (SECURITY)
SecurityLab
University of Oslo
+47 40347666
|