Feature/151 manual step capability #153
Conversation
MaartendeKruijf
force-pushed
the
feature/151-manual-step-capability
branch
4 times, most recently
from
2c287ad
to
9377783
Compare
MaartendeKruijf
force-pushed
the
feature/151-manual-step-capability
branch
from
9377783
to
7e1d853
Compare
MaartendeKruijf
force-pushed
the
feature/151-manual-step-capability
branch
from
7e1d853
to
02e9d94
Compare
MaartendeKruijf
force-pushed
the
feature/151-manual-step-capability
branch
from
02e9d94
to
6ac7757
Compare
MaartendeKruijf
force-pushed
the
feature/151-manual-step-capability
branch
from
779b888
to
8492799
Compare
| |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.
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.
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 |
| |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.
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.
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.
"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.
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 targets 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.