Add nested playbooks

[VVX7]

Problem

Currently playbooks are flat lists of response actions. This can be difficult to maintain when playbooks grow in number or complexity.

Solution

Playbooks should be allowed to contain references to other playbooks in addition to response actions.

When exported to TheHive nested playbooks must be flattened (possibly with some tag/prefix to identify specific tasks as members of child playbooks) so that they can be used as Tasks.

[yugoslavskiy]

@VVX7,

I don't see how we can put one playbook into another and make the list of tasks expandable in case of need.

we've worked out this problem using workflow (free text) section of the Playbook.
take a look at point #3:

atomic-threat-coverage/response_playbooks/RP_0001_phishing_email.yml

Lines 33 to 37 in ea6cda3

	workflow: |
	1. Execute Response Actions step by step. Some of them directly connected, which means you will not be able to move forward not finishing previous step
	2. Start executing containment and eradication stages concurrently with next identification steps, as soon as you will receive infomration about malicious hosts
	3. If phishing led to code execution or remote access to victim host, immediately start executing Generic Post Exploitation Incident Response Playbook
	4. Save all timestamps of implemented actions in Incident Report draft on the fly, it will save a lot of time

Maybe this is something that could help?

If you need fully automated nesting, this is not something TheHive can offer at the moment.
But if we will integrate support of COPS in our Response Actions/Playbooks, it could fly in Demisto IRP.

What do you guys think? @sn0w0tter @mrblacyk

[VVX7]

Here is an example to make sure we're thinking of the same thing.

Playbook 1

• red
• blue
• green
• black

Playbook 2

• red
• blue
• yellow
• black

Steps red and blue are sequential actions and common to both playbooks. This can be refactored to:

Playbook 1

• playbook 3
• green
• black

Playbook 2

• playbook 3
• yellow
• black

Playbook 3

• red
• blue

Where in playbook 1 and 2 the response actions are automatically imported to look like the original example, and any workflow is concatenated in order of playbook import.

[mrblacyk]

Hey @VVX7,

I can see how it can be useful.

Right now, we have Response Actions category in its name so technically we could just consume the list of RAs from nested RP and append accordingly. However, single RP contains RA from potentially all steps of 6-step SANS IR process. There is an issue of order and placement of nested RP.

I can see a one solution to this problem. Let's put nested RP as a step for identification. Let's say that the above example is related to one step only - identification. The function will retrieve identification RAs from a nested RP (Playbook 3) and insert to the Playbook 2 at the location of playbook 3. So, starting with:

Playbook 2

Identification

• yellow
• playbook 3
• black

Playbook 3

Identification

• red
• blue

We end up with:

Playbook 2

Identification

• yellow
• red
• blue
• black

The order does matter. If the playbook 3 was placed after yellow and black, it would have been appended at the end instead.

---

What do you think? Would it be suitable for this?

Of course, I also can think of an additional field for including whole playbooks but the order would be a problematic part and would like to hold with such a feature for time being.

[mrblacyk]

I can also see now that it may be a bit confusing. This approach mandates that inclusion of nested RP needs to be repeated for every IR step.

[VVX7]

That could work. You're correct that the RA order needs to be maintained and that nested RP must be included for each IR phase (and I've added more phases in my AMITT PR too).