-
Notifications
You must be signed in to change notification settings - Fork 0
DOD Incidents and CACAO playbooks
We are referring to the current proposal from the DOD schema here. An incident sample activity here.
There are a lot of overlaps in functionality between the incident response model and the workflow of CACAO playbook model. One would say that the incident response should be a super set of the workflow model but in any case we should reduce the data structures between the two to provide a better integration and modelling capabilities.
Following some suggestions.
This is an example of a task triggering a CACAO playbook. A few comments:
- this is the playbook ID: playbook--a361b0e4-d81b-43f7-ba45-a131aa3b8080 which is stored in our data model, this makes sense
- this playbook step is confusing: action--e984e66e-e92b-4ba1-b7a7-a319aa5c58cd, it should be pointing to a start step like so: "start--fa16a4e9-e6b9-4658-b464-ca1632ff57f4"
- changed object: this is very fuzzy how can the playbook affect the state of the grouping object in this case a user account? Depending on the playbook type there may be many ways the playbook interact with an SDO. I am not sure we want to go to this level of granularity right in this version. I suggest we remove this feature for now.
{
"type": "task",
"id": "task--9ceb67a5-5c5e-4d2c-8fa1-044c91445e49",
"created": "2020-10-19T01:01:01.000Z",
"modified":"2020-10-19T01:01:01.000Z",
"spec_version": "2.1",
"task_type": "playbook-step-execution",
"name": "get new accounts",
"outcome": "successful",
"external_references": [
{
"source_name": "internal-playbooks",
"external_id": "playbook--a361b0e4-d81b-43f7-ba45-a131aa3b8080"
},
{
"source_name": "playbook-step",
"external_id": "action--e984e66e-e92b-4ba1-b7a7-a319aa5c58cd"
}
],
"changed_objects": [
{
"state_change_type": "output",
"result_ref": "grouping--5ae578cf-5884-45f4-a1bf-1998af828ccc"
}
],
"extensions": {
"extension-definition--2074a052-8be4-4932-849e-f5e7798e0030": {
"extension_type": "new-sdo"
}
}
},
{
"type": "grouping",
"spec_version": "2.1",
"id": "grouping--5ae578cf-5884-45f4-a1bf-1998af828ccc",
"created": "2023-04-28T23:35:32.099185Z",
"modified": "2023-04-28T23:35:32.099185Z",
"context": "suspicious-activity",
"object_refs": [
"user-account--a5549db1-1a61-5905-ad16-3cc14b35cd22"
]
},
A list of activities tied to this incident. Each activity-entry MUST reference either a Task or Event. This list MUST not contain cycles.
| Property Name | Type | Description |
|---|---|---|
| activity_ref (required) | identifier | The identity of the event or task that is described by this entry. Within an Incident this MUST reference either a Task or Identity.When used within a Task this MUST only reference other Task objects. When used within a Event this MUST only reference other Event objects. |
| next_steps (optional) | list of type activity-sequence-entry | A list of activity sequences that describes how the activities that compose the parent object flow into each other. |
This is confusing because in CACAO the next_step properties, does not indicate sequentiality but: A parallel step MUST execute all workflow steps that are part of the next_steps property before this step can be considered complete and the workflow logic moves on.
Therefore if we want to decide in our case:
- it his a parallel activity?
- are next steps ALL required to complete or are all optional?
- on_completion: I am guessing this is the equivalent of result_ref?
"step--46c1d6e1-874e-4588-b2a4-16d31634372c": {
"type": "parallel",
"next_steps": [
"step--9afbcb12-8f82-4d35-ba70-f755b83725e1",
"step--b4161d26-1c8d-4f19-b82f-aad144de4828"
],
"on_completion": "step--44924d92-58c9-4fcc-9435-6fb651dbbddd"
}
Activity sequences entries stored references to a subsequent step for an activity entry. As these are always stored in an array of steps within an array of activity entries validation rules for step_ref MUST be performed against the entire array of activity entries.
| Property Name | Type | Description |
|---|---|---|
| step_ref (required) | identifier | The identity of the event or task that is described by this entry.This reference MUST be included as an activity_ref within the parent array of activity-entry objects. Within this array there MUST not be any cyclical references. |
| condition_type (required) | activity-condition-enum | If the referenced step required the current one to be successful. If it is optional, or if it is unknown. |
| transition_type (required) | activity-transition-enum | What state the referenced step depends on. If it is performed upon success, failure, simple completion, or if it is unknown. |
This is too complicated and could be implemented like in a the Conditional Step of CACAO.
We want to propose the following approach:
- we keep the incident core as it is
- we remove the activity objects
- instead we "borrow" the CACAO workflow step:
- use a type = incident-step-type (or similar to mimick the CACAO approach)
- merge the Task type and the Activity and Activity Sequence into effectively one object
- remove the delay, timeout, step_variables, owner and step_extensions
- include the properties we care about like start_time and end_time
- introduce the same vocabulary: start, end, single, playbook, parallel, if-condition, while-condition, switch-condition (maybe we take out the while-condition and switch-condition for now)
- the playbook step will work nicely because it operates the exact same function
- state change object: I believe this should be linked to a command-type step in CACAO playbook to resolve the fuzzy semantic explained before, for example a an OpenC2 step will be the initial_ref and the result_ref will be a DDOS prevention impact etc...