OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Action Item: OpenC2 "Liaison" with CACAO


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

 

From: Dave Lemire <dave.lemire@g2-inc.com>
Sent: Wednesday, September 25, 2019 11:08 AM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: Brule, Joseph M <jmbrule@radium.ncsc.mil>; David Kemp <Dkemp@mobility-challenge.com>; Vasileios Mavroeidis <vasileim@ifi.uio.no>; OpenC2CoChairs <openc2-committee-chairs@lists.oasis-open.org>
Subject: Re: Action Item: OpenC2 "Liaison" with CACAO

 

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.

 

Dave

--

David P. Lemire, CISSP

HII Mission Driven Innovative Solutions (HII-MDIS, formerly G2, Inc.)

Technical Solutions (A Division of Huntington Ingalls Industries)

  OpenC2 Technical Committee Secretary
  OpenC2 Implementation Considerations SC Co-chair
  Contractor support to NSA
Email: dave.lemire@g2-inc.com / david.lemire@hii-tsd.com
Work (301) 575-5190 | Mobile (240) 938-9350

 

On Tue, Sep 24, 2019 at 8:03 PM duncan sfractal.com <duncan@sfractal.com> wrote:

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.com
Cc: 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? 

 

From: David Kemp <Dkemp@mobility-challenge.com>
Sent: Tuesday, September 24, 2019 12:29 PM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; 'Vasileios Mavroeidis' <vasileim@ifi.uio.no>; duncan sfractal.com <duncan@sfractal.com>; David Kemp <Dkemp@mobility-challenge.com>
Cc: dave.lemire <dave.lemire@g2-inc.com>; OpenC2CoChairs <openc2-committee-chairs@lists.oasis-open.org>
Subject: [Non-DoD Source] RE: Action Item: OpenC2 "Liaison" with CACAO

 

Not a âcontroversyâ, but there are legitimate points of discussion

 

JSON Schemahttps://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.8.3strikes precisely the right balance between M2M and human factors:

    8.3 Comments with $comment
    â Implementations MUST NOT present this string to end users.

    â 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

 

 

From: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Tuesday, September 24, 2019 11:32 AM
To: 'Vasileios Mavroeidis' <vasileim@ifi.uio.no>; duncan sfractal.com <duncan@sfractal.com>
Cc: dave.lemire <dave.lemire@g2-inc.com>; OpenC2CoChairs <openc2-committee-chairs@lists.oasis-open.org>
Subject: RE: Action Item: OpenC2 "Liaison" with CACAO

 

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? 

 

From: Vasileios Mavroeidis <vasileim@ifi.uio.no>
Sent: Tuesday, September 24, 2019 10:45 AM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: Vasileios Mavroeidis <vasileim@ifi.uio.no>; dave.lemire <dave.lemire@g2-inc.com>; OpenC2CoChairs <openc2-committee-chairs@lists.oasis-open.org>
Subject: [Non-DoD Source] Re: Action Item: OpenC2 "Liaison" with CACAO

 

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.

 

 

Best,

 

Vasileios Mavroeidis â Security Researcher and Ph.D. Research Fellow 
Research Group of Information and Cyber Security (SECURITY)
SecurityLab
University of Oslo  
+47 40347666

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]