Thanks Mateusz, I'll have a look. As Bret points out playbook variables have global scope, so applications need to know how to behave when receiving a playbook with variables of the same name. The options include:
namespacing: step variables are qualified by the step id: "start--07bea005-4a36-4a77-bd1f-79a6e4682a13:x"
shadowing: a local variable "x" makes the global "x" unavailable within the step
runtime error: reading a playbook with colliding variables throws an error
static error: creating a playbook with colliding variables throws an error
Saying "best practice: don't do it" is fine, but leads to undetermined results when someone does it.
------------------------------
David Kemp
National Security Agency
------------------------------
Original Message:
Sent: 07-19-2024 05:36
From: Mateusz Zych
Subject: CACAO Schema
Dear David,
The same schemas are used in the
CACAO Roaster to validate the playbooks.
Best regards,
Mateusz Zych
Digital Security Group
University of Oslo
Original Message:
Sent: 7/18/2024 1:58:00 PM
From: David Kemp
Subject: CACAO Schema
At the most recent meeting there was discussion variable name collisions, with a recommendation to prohibit playbook variables and step variables from having the same name. One of the discussion topics was "let authors be authors, anything we prohibit we have to check, and checking is undesirable"
But that led to the question of what to check. I looked in the spec working draft and the TC GitHub and can't find the CACAO schema. There are playbook examples, and there are layout schemas, but where is the CACAO schema that would validate the playbook examples? It appears to me that there is no possibility of playbook variables and step variables colliding because they are in different scopes. Both the playbook and 3 different steps within a workflow could each have a variable named "x" and there can be no confusion because the playbook's "x" and the start step's "x" have nothing to do with the second step's "x":
"markings": [
"marking-statement--6424867b-0440-4885-bd0b-604d51786d06",
"marking-tlp--bab4a63c-aed9-4cf5-a766-dfca5abac2bb"
],
"playbook_variables": {
"__data_exfil_site__": {
"type": "ipv4-addr",
"description": "The IP address for the data exfiltration site",
"value": "1.2.3.4"
},
"x": "foo"
},
"workflow_start": "start--07bea005-4a36-4a77-bd1f-79a6e4682a13",
"workflow_exception": " ... ",
"workflow": {
"start--07bea005-4a36-4a77-bd1f-79a6e4682a13": {
"type": "start",
"name": "Start Playbook Example 1",
"on_completion": "action--7f40f9d7-de39-4027-ab97-15035beff2ff",
"step_variables": {
"x": "bar"
}
}
If this is true, I'm not sure what the discussion was about. But it led to the schema question above, which would provide the definitive answer without resorting to (incomplete) examples. How do you validate a playbook?
------------------------------
David Kemp
National Security Agency
------------------------------