-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/151 manual step capability #153
base: development
Are you sure you want to change the base?
Conversation
2c287ad
to
9377783
Compare
9377783
to
7e1d853
Compare
7e1d853
to
02e9d94
Compare
02e9d94
to
6ac7757
Compare
779b888
to
8492799
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The setup looks good to me! But there are some details that we might want to align on
|command |command |string |The command for the agent either command | ||
|command_is_base64 |true \| false |bool |Indicate the command is in base 64 | ||
|targets |cacao agent-target |dictionary |Map of [cacao agent-target](https://docs.oasis-open.org/cacao/security-playbooks/v2.0/cs01/security-playbooks-v2.0-cs01.html#_Toc152256509) with the target(s) of this command | ||
|in_args |cacao variables |dictionary |Map of [cacao variables](https://docs.oasis-open.org/cacao/security-playbooks/v2.0/cs01/security-playbooks-v2.0-cs01.html#_Toc152256555) handled in the step in args with current values and definitions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would discurage in any case the use and reporting of in_args, as I don't think there's really any way to use them. They should be already resolved in the command
if any
|
||
|
||
|
||
|field |content |type | description | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a list of manual command action steps right? The return payload as presented is only for one such steps? I see that in the example it's indeed a list, but maybe we should mention it here in this response bit too
|command |command |string |The command for the agent either command | ||
|command_is_base64 |true \| false |bool |Indicate the command is in base 64 | ||
|targets |cacao agent-target |dictionary |Map of [cacao agent-target](https://docs.oasis-open.org/cacao/security-playbooks/v2.0/cs01/security-playbooks-v2.0-cs01.html#_Toc152256509) with the target(s) of this command | ||
|in_args |cacao variables |dictionary |Map of [cacao variables](https://docs.oasis-open.org/cacao/security-playbooks/v2.0/cs01/security-playbooks-v2.0-cs01.html#_Toc152256555) handled in the step in args with current values and definitions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above
|playbook_id |UUID |string |The id of the CACAO playbook executed by the execution | ||
|step_id |UUID |string |The id of the step executed by the execution | ||
|response_status |enum |string |Can be either `success` or `failed` | ||
|response_out_args |cacao variables |dictionary |Map of [cacao variables](https://docs.oasis-open.org/cacao/security-playbooks/v2.0/cs01/security-playbooks-v2.0-cs01.html#_Toc152256555) handled in the step out args with current values and definitions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking whether we should also expect, as part of the out_arg info, anything else besides the arg (variable) name, and its value.
Perhaps it may make sense to allow passing back type
, and description
if we can have a wildcard for it (but would we want a wildcard variable? That could mean inconsistent executions? Or else imply that a wildcard variable is properly handled in a playbook?). But constant
and external
? I am not sure
"response_out_args": { | ||
"<variable-name-1>" : { | ||
"type": "<type>", | ||
"name": "<variable-name>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By definition of a variable type, there is no name
property within it. Do we need to have it as property here?
|
||
#### Success and failure | ||
|
||
The manual step is considered successful if a response is made through the [manual api](/docs/core-components/api-manual). The manual command can specify a timeout but if none is specified SOARCA will use a default timeout of 10 minutes. If a timeout occurs the step is considered as failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the step is considered as failed"
due to ambiguity of success
and failure
in CACAO V2, I would explicitly say that this is the choice we make to manage this event. So we either incur in workflow exception step if defined, or just fail the execution.
"action--7777c6b6-e275-434e-9e0b-d68f72e691c1": { | ||
"type": "action", | ||
"agent": "soarca--00010001-1000-1000-a000-000100010001", | ||
"targets": ["linux--c7e6af1b-9e5a-4055-adeb-26b97e1c4db7"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might also want to mention better how we interpret agents and targets for a manual step. By CACAO specification, one would argue that the agent
should be the entity performing the manual act itself, and target
s the systems on which such act is carried out.
But it makes sense to also see SOARCA as agent
of the manual action step, because it's implemented per SOARCA interface. Also, irrespective of whatever method to collect the return data is used, the manual step should end with someone pushing the out args values to SOARCA via APIs (safe for 3P connectors I think?).
So yeah overall we might want to explain this interpretation of agents/targets/division of responsibilities in the documentation.
No description provided.