OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu

I ve figured out what for me seems off about the Attacker target type - it's that the definition of "target" shifts and expands.
 
In Section 9.14, the definition of the target data type is "The target data type captures detailed information about
the entities or devices that accept, receive, process, or execute one or more commands as defined in a workflow step "

 
The Attacker target type adds dimensions (executor and subject), which makes me question the spec s use of the term Target (something I ve mentioned before). It might be helpful to consider the OpenC2 Command object. It has four main
components, two required and two optional:
 
* Action (required) - the " verb ." The task or activity to be performed. I think this is like the
commands
property of the CACAO Action Step.
 
* Target (required) - the " object " of the Action. The Action is performed on the Target. This doesn't seem to correspond to a property of the CACAO Action Step, but I think this is what the Attacker target type defines via
its subject
property.
 
* Actuator (optional) - the " subject " of the Action. The Actuator executes the Action on the Target. I think this is like the
targets property of the CACAO Action Step (and as defined in Section 9.14), as well as the
executor property of the Attacker target type.
 
* Args (optional) provide additional info on how the command is to be performed. This is like the
in_args / out_args of the CACAO Action Step.
 
I think what seems off to me is that the Attacker target type considers both Target (subject) and Actuator (executor), which the rest of the spec does not. However, I think the rest of the spec
should define both concepts. This would change the way the Attack target type is defined hopefully in a way that feels right. Another odd thing about Attacker target type is that the subject is of type

target which doesn t work with the Section 9.14 definition.
 
Also, the text in Section 4.5 for Action Step says, "This workflow step contains the actual commands to be executed
on one or more targets " - which suggests a target is an object (Target in OpenC2) rather than the subject (Actuator in OpenC2) as defined in Section 9.14.
 
I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.
Thanks,
Dez
 
 


From: Dr. Desiree A Beck
Sent: Tuesday, November 1, 2022 2:55 PM
To: Bret Jordan <jordan.oasisopen@gmail.com>; cacao@lists.oasis-open.org
Subject: RE: [EXT] [cacao] Remaining work items


 
Regarding the attack target types I agree with Bret that something seems off, but I can t articulate anything specific at the moment. I ll be thinking about it and will respond with details soon
Dez
 

From: cacao@lists.oasis-open.org < cacao@lists.oasis-open.org >
On Behalf Of Bret Jordan
Sent: Thursday, October 27, 2022 1:24 PM
To: cacao@lists.oasis-open.org
Subject: [EXT] [cacao] Remaining work items

 

All,

 


We have very few remaining work items that need to be addressed before we can ship the next version of the CACAO specification. We really need people to speak up and voice their opinions on the following:


 


1) MITRE/DHS has proposed a new property to track some of the features of a playbook. Several people seem to like this and support this. However, there is some concern on if this property should be "required" or if it should be "optional".
Allan strongly views this should be optional. MITRE/DHS really want it to be required. But I have not heard from the rest of you. 


 


Please respond to this email with your views on this subject.


 


2) A while back Allan proposed the attack target types. I think we all generally agree that this is a good idea. However, when I have played around with it, it feels like there are some minor issues with the modeling. I have not yet been
able to put my finger on it. To be clear I really like the idea of the Attack stuff that Allan proposed and really want it. But something just feels off with it. Has anyone else seen issues while playing around with it? 


 


Bret


 

Hi Dez - Your suggestion I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.   Was  exactly what we had discussed on a call that I attended where we went over the attack framework.  Basically the term  target  in cacao has been used to represent both a system that executes a command as part of action and also the target of an attack being executed by a system executing an attack simulation against the target. Command is the thing that executes on that target.  So in my mind  Cacao  target == OpenC2 Actuator Cacao command == OpenC2 Target Cacao action == a combined instruction (with logic) that may define Cacao target or list of +Cacao command. There is no equivalent (I believe) in OpenC2 to this concept. Cacao workflow is a set of Cacao actions. I guess this prior discussion didn t stick and I appreciate you sharing how OpenC2 has defined some aspects of this. However, one of the primary reasons why CACAO exists is that OpenC2 didn t support all that we needed to do and after working with folks in OpenC2 it was obvious that we need to form a playbook TC that would allow us to define playbooks that could include the various elements defined such as OpenC2, Kestrel etc. One suggestion that I thought we had also previously discussed was changing the name of the attack  target to something more specific such as  AttackVictim or just  Victim . This might be a less intrusive change than changing all uses of the term target everywhere else. Allan On Nov 2, 2022, at 1:26 AM, Dr. Desiree A Beck <dbeck@mitre.org> wrote: I ve figured out what for me seems off about the Attacker target type - it's that the definition of target shifts and expands.   In Section 9.14, the definition of the target data type is The target data type captures detailed information about the entities or devices that accept, receive, process, or execute one or more commands as defined in a workflow step   The Attacker target type adds dimensions (executor and subject), which makes me question the spec s use of the term Target (something I ve mentioned before). It might be helpful to consider the OpenC2 Command object. It has four main components, two required and two optional:   * Action (required) - the verb . The task or activity to be performed. I think this is like the commands property of the CACAO Action Step.   * Target (required) - the object of the Action. The Action is performed on the Target. This doesn't seem to correspond to a property of the CACAO Action Step, but I think this is what the Attacker target type defines via its subject property.   * Actuator (optional) - the subject of the Action. The Actuator executes the Action on the Target. I think this is like the targets property of the CACAO Action Step (and as defined in Section 9.14), as well as the executor property of the Attacker target type.   * Args (optional) provide additional info on how the command is to be performed. This is like the in_args / out_args of the CACAO Action Step.   I think what seems off to me is that the Attacker target type considers both Target (subject) and Actuator (executor), which the rest of the spec does not. However, I think the rest of the spec should define both concepts. This would change the way the Attack target type is defined hopefully in a way that feels right. Another odd thing about Attacker target type is that the subject is of type target which doesn t work with the Section 9.14 definition.   Also, the text in Section 4.5 for Action Step says, This workflow step contains the actual commands to be executed on one or more targets - which suggests a target is an object (Target in OpenC2) rather than the subject (Actuator in OpenC2) as defined in Section 9.14.   I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined. Thanks, Dez     From: Dr. Desiree A Beck Sent: Tuesday, November 1, 2022 2:55 PM To: Bret Jordan <jordan.oasisopen@gmail.com>; cacao@lists.oasis-open.org Subject: RE: [EXT] [cacao] Remaining work items   Regarding the attack target types I agree with Bret that something seems off, but I can t articulate anything specific at the moment. I ll be thinking about it and will respond with details soon Dez   From: cacao@lists.oasis-open.org < cacao@lists.oasis-open.org > On Behalf Of Bret Jordan Sent: Thursday, October 27, 2022 1:24 PM To: cacao@lists.oasis-open.org Subject: [EXT] [cacao] Remaining work items   All,   We have very few remaining work items that need to be addressed before we can ship the next version of the CACAO specification. We really need people to speak up and voice their opinions on the following:   1) MITRE/DHS has proposed a new property to track some of the features of a playbook. Several people seem to like this and support this. However, there is some concern on if this property should be required or if it should be optional . Allan strongly views this should be optional. MITRE/DHS really want it to be required. But I have not heard from the rest of you.    Please respond to this email with your views on this subject.   2) A while back Allan proposed the attack target types. I think we all generally agree that this is a good idea. However, when I have played around with it, it feels like there are some minor issues with the modeling. I have not yet been able to put my finger on it. To be clear I really like the idea of the Attack stuff that Allan proposed and really want it. But something just feels off with it. Has anyone else seen issues while playing around with it?    Bret  

Hi Allan,
 
For me, the term "target" carries meaning in cybersecurity (outside of CACAO), and I find it confusing to have it represent a system that executes a command. We discussed it only briefly when reviewing a playbook example I put together,
but I think the terms "executor" or "implementer" were mentioned as possible alternatives.
 
Also, I wasn't suggesting that we use the OpenC2 terminology. It was just that I thought its breakdown of roles might be helpful because it feels like target/actuator roles are being conflated in CACAO. But it sounds like maybe the conflation
is intentional?
 
For me, saying that a target is "a system that executes a command" and also that a command "executes on a target" is especially confusing in the context of manual processing targets (e.g., Individual Target). If a person (Individual Target)
executes a manual command on a server, what is the server? I think it s a Security Infrastructure Category Target - so then one target executes on another target? It seems more straightforward to consider the individual an "executor" and the server a "target."
 
When you suggest changing the name of the attack target (your bold font), do you mean that the list of "targets" would simply include "Victim" instead of "Attacker Target" (i.e., Individual Target, Group Target, ..., Victim, ... Kali Linux
Target)?
 
Thanks,
Dez
 


From: aa tt <atcyber1000@gmail.com>
Sent: Wednesday, November 2, 2022 7:46 PM
To: Dr. Desiree A Beck <dbeck@mitre.org>
Cc: Bret Jordan <jordan.oasisopen@gmail.com>; cacao@lists.oasis-open.org
Subject: Re: [cacao] [EXT] [cacao] Remaining work items


 
Hi Dez - Your suggestion "I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.  Was exactly what we had discussed on a call that I attended where we went over the attack
framework. 

 


Basically the term  target  in cacao has been used to represent both a system that executes a command as part of action and also the target of an attack being executed by a system executing an attack simulation against the target. Command
is the thing that executes on that target. 


 


So in my mind 


 


Cacao target == OpenC2 Actuator


Cacao command == OpenC2 Target


Cacao action == a combined instruction (with logic) that may define Cacao target or list of +Cacao command. There is no equivalent (I believe) in OpenC2 to this concept.


Cacao workflow is a set of Cacao actions.


 


I guess this prior discussion didn t stick and I appreciate you sharing how OpenC2 has defined some aspects of this. However, one of the primary reasons why CACAO exists is that OpenC2 didn t support all that we needed to do and after working
with folks in OpenC2 it was obvious that we need to form a playbook TC that would allow us to define playbooks that could include the various elements defined such as OpenC2, Kestrel etc.


 


One suggestion that I thought we had also previously discussed was changing the name of the attack  target to something more specific such as  AttackVictim or just  Victim . This might be a less intrusive change than changing all uses
of the term target everywhere else.


 

Allan








On Nov 2, 2022, at 1:26 AM, Dr. Desiree A Beck < dbeck@mitre.org > wrote:

 


I ve figured out what for me seems off about the Attacker target type - it's that the definition of "target" shifts and expands.
 
In Section 9.14, the definition of the target data type is "The target data type captures detailed information about
the entities or devices that accept, receive, process, or execute one or more commands as defined in a workflow step "

 
The Attacker target type adds dimensions (executor and subject), which makes me question the spec s use of the term Target (something I ve mentioned before). It might be helpful to consider the OpenC2 Command object. It has four main
components, two required and two optional:
 
* Action (required) - the " verb ." The task or activity to be performed. I think this is like the
commands
property of the CACAO Action Step.
 
* Target (required) - the " object " of the Action. The Action is performed on the Target. This doesn't seem to correspond to a property of the CACAO Action Step, but I think this is what the Attacker target type defines via
its subject
property.
 
* Actuator (optional) - the " subject " of the Action. The Actuator executes the Action on the Target. I think this is like the
targets property of the CACAO Action Step (and as defined in Section 9.14), as well as the
executor property of the Attacker target type.
 
* Args (optional) provide additional info on how the command is to be performed. This is like the
in_args / out_args of the CACAO Action Step.
 
I think what seems off to me is that the Attacker target type considers both Target (subject) and Actuator (executor), which the rest of the spec does not. However, I think the rest of the spec
should define both concepts. This would change the way the Attack target type is defined hopefully in a way that feels right. Another odd thing about Attacker target type is that the subject is of type

target which doesn t work with the Section 9.14 definition.
 
Also, the text in Section 4.5 for Action Step says, "This workflow step contains the actual commands to be executed
on one or more targets " - which suggests a target is an object (Target in OpenC2) rather than the subject (Actuator in OpenC2) as defined in Section 9.14.
 
I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.
Thanks,
Dez
 
 


From: Dr. Desiree A Beck
Sent: Tuesday, November 1, 2022 2:55 PM
To: Bret Jordan < jordan.oasisopen@gmail.com >;
cacao@lists.oasis-open.org
Subject: RE: [EXT] [cacao] Remaining work items


 
Regarding the attack target types I agree with Bret that something seems off, but I can t articulate anything specific at the moment. I ll be thinking about it and will respond with details soon
Dez
 

From: cacao@lists.oasis-open.org < cacao@lists.oasis-open.org >
On Behalf Of Bret Jordan
Sent: Thursday, October 27, 2022 1:24 PM
To: cacao@lists.oasis-open.org
Subject: [EXT] [cacao] Remaining work items

 

All,

 


We have very few remaining work items that need to be addressed before we can ship the next version of the CACAO specification. We really need people to speak up and voice their opinions on the following:


 


1) MITRE/DHS has proposed a new property to track some of the features of a playbook. Several people seem to like this and support this. However, there is some concern on if this property should be "required" or if it should be "optional".
Allan strongly views this should be optional. MITRE/DHS really want it to be required. But I have not heard from the rest of you. 


 


Please respond to this email with your views on this subject.


 


2) A while back Allan proposed the attack target types. I think we all generally agree that this is a good idea. However, when I have played around with it, it feels like there are some minor issues with the modeling. I have not yet been
able to put my finger on it. To be clear I really like the idea of the Attack stuff that Allan proposed and really want it. But something just feels off with it. Has anyone else seen issues while playing around with it? 


 


Bret


 







 

>   it was obvious that we need to form a playbook TC






Yes.


OpenC2 defines an API between automated systems that supports both small atomic actions and high-level (conceptual) actions like investigate, mitigate and remediate.

CACAO defines data objects (playbooks) that can both call for atomic actions and be carried as parameters of high-level actions to translate intent into detail.  With the discussion of is_executable I infer that playbooks provide another level of translation,
from template to executable.

You may be interested in another related activity: the proposed "Heimdall Data Format" OASIS TC.  According to Chet Ensign the schedule looks like:


- start call for comment - 11/1

- end call for comment - 11/14

- convener call - 11/16

- call for participation - 11/17

- TC kickoff meeting - 12/16



Officially,
the TC will be listed as an active project when the call for participation going out on the 17th.


though I haven't seen the call for comment yet.


HDF is a component of MITRE's
Security Automation Framework  for examining systems for vulnerabilities and performing corrective action.  It includes 'check texts' and 'fix texts' that are, as the name implies, scripts rather than structured data playbooks, but there may be some common
interests between the TCs.

Regards,
David



From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Sent: Wednesday, November 2, 2022 7:45 PM
To: Dr. Desiree A Beck <dbeck@mitre.org>
Cc: Bret Jordan <jordan.oasisopen@gmail.com>; cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>
Subject: Re: [cacao] [EXT] [cacao] Remaining work items
 

Hi Dez - Your suggestion " I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.   Was  exactly
what we had discussed on a call that I attended where we went over the attack framework. 


Basically the term  target  in cacao
has been used to represent both a system that executes a command as part of action and also the target of an attack being executed by a system executing an attack simulation against the target. Command is the thing that executes on that target. 


So in my mind 


Cacao  target == OpenC2 Actuator
Cacao command == OpenC2 Target
Cacao action == a combined instruction (with logic) that may define Cacao target or list of +Cacao command. There is no equivalent (I believe) in OpenC2 to this concept.
Cacao workflow is a set of Cacao actions.


I guess this prior discussion didn t stick and I appreciate you sharing how OpenC2 has defined some aspects of
this. However, one of the primary reasons why CACAO exists is that OpenC2 didn t support all that we needed to do and after working with folks in OpenC2 it was obvious that we need
to form a playbook TC that would allow us to define playbooks that could include the various elements defined such as OpenC2, Kestrel etc.


One suggestion that I thought we had also previously discussed was changing the name of the attack  target to something more specific such as  AttackVictim or just  Victim . This
might be a less intrusive change than changing all uses of the term target everywhere else.


Allan











On Nov 2, 2022, at 1:26 AM, Dr. Desiree A Beck <dbeck@mitre.org> wrote:






I ve figured out what for me seems off about the Attacker target type - it's that the definition of "target" shifts and expands.

 

In Section 9.14, the definition of the target data type is "The target data type captures detailed information about
the entities or devices that accept, receive, process, or execute one or more commands as defined in a workflow step "


 

The Attacker target type adds dimensions (executor and subject), which makes me question the spec s use of the term Target (something I ve mentioned before). It might be helpful to consider the OpenC2 Command object. It has four main components, two required
and two optional:

 

* Action (required) - the " verb ." The task or activity to be performed. I think this is like the
commands
property of the CACAO Action Step.

 

* Target (required) - the " object " of the Action. The Action is performed on the Target. This doesn't seem to correspond to a property of the CACAO Action Step, but I think this is what the Attacker target type defines via its
subject
property.

 

* Actuator (optional) - the " subject " of the Action. The Actuator executes the Action on the Target. I think this is like the
targets property of the CACAO Action Step (and as defined in Section 9.14), as well as the
executor property of the Attacker target type.

 

* Args (optional) provide additional info on how the command is to be performed. This is like the
in_args / out_args of the CACAO Action Step.

 

I think what seems off to me is that the Attacker target type considers both Target (subject) and Actuator (executor), which the rest of the spec does not. However, I think the rest of the spec
should define both concepts. This would change the way the Attack target type is defined hopefully in a way that feels right. Another odd thing about Attacker target type is that the subject is of type

target which doesn t work with the Section 9.14 definition.

 

Also, the text in Section 4.5 for Action Step says, "This workflow step contains the actual commands to be executed
on one or more targets " - which suggests a target is an object (Target in OpenC2) rather than the subject (Actuator in OpenC2) as defined in Section 9.14.

 

I suggest that the TC reconsider the term target as well as consider whether both target and actuator should be defined.

Thanks,

Dez

 

 



From: Dr. Desiree A Beck
Sent: Tuesday, November 1, 2022 2:55 PM
To: Bret Jordan <jordan.oasisopen@gmail.com>; cacao@lists.oasis-open.org
Subject: RE: [EXT] [cacao] Remaining work items



 

Regarding the attack target types I agree with Bret that something seems off, but I can t articulate anything specific at the moment. I ll be thinking about it and will respond with details soon

Dez

 


From:
cacao@lists.oasis-open.org < cacao@lists.oasis-open.org >
On Behalf Of Bret Jordan
Sent: Thursday, October 27, 2022 1:24 PM
To:
cacao@lists.oasis-open.org
Subject: [EXT] [cacao] Remaining work items


 


All,


 



We have very few remaining work items that need to be addressed before we can ship the next version of the CACAO specification. We really need people to speak up and voice their opinions on the following:



 



1) MITRE/DHS has proposed a new property to track some of the features of a playbook. Several people seem to like this and support this. However, there is some concern on if this property should be "required" or if it should be "optional". Allan strongly views
this should be optional. MITRE/DHS really want it to be required. But I have not heard from the rest of you. 



 



Please respond to this email with your views on this subject.



 



2) A while back Allan proposed the attack target types. I think we all generally agree that this is a good idea. However, when I have played around with it, it feels like there are some minor issues with the modeling. I have not yet been able to put my finger
on it. To be clear I really like the idea of the Attack stuff that Allan proposed and really want it. But something just feels off with it. Has anyone else seen issues while playing around with it? 



 



Bret