Extend the Response Action schema to facilitate additional information

[pjabes]

Presently, a given Response Action will render a page with the following fields title, id, description, author, creation_date, stage, references, workflow. Various stakeholders have requested the ability to add additional information into a response action to enrich the value that it provides to analysts.

By way of an example, given RA2602 - Remove User Account of a compromised service account may result in an unintended impact to the business. Some SOCs may want to tag this action with some further details specifying the rating of business impact that could potentially occur.

[yugoslavskiy]

Hello @pjabes , @xofolowski! Thank you for your continuous contribution!

The details field (dictionary) with custom sub-fields looks great. A lot of people will benefit from it. Could you please create a separate PR to develop branch for it? (:

[d3anp]

Excellent work as always team. Would a dictionary allow for multiple values to be captured against each field? Could the value of a dict entry be a list?

A use case for a custom details field would be requires where values could hypothetically be domain_admin and vpn_admin where both of these permissions are required to remove a users access from an environment in a contain account comprise RA. Capturing the requirements data in an RA could support a few use cases, the following come to mind:

• For new analysts joining a team a few quick greps and you could work how the level of access required.
• Where a capability is impacted (vpn_admin is removed or business case is under question), a few quick greps could justify the roles reinstatement.

Another use cause could be to capture the automation endpoints used for RA's that are automated for similar use cases.

[xofolowski]

@d3anp - that shouldn't be a problem at all. For example, you could have in your yaml

details:
    requires:
        privileges:
            - domain_admin
            - vpn_admin

In your jinja template, you could then just add a section, let's say "requirements", draw a table and for the cell containing "privileges" just iterate over the list contained in details['requires']['privileges'].

HTH

[xofolowski]

Another idea that just pops into my mind: If any RA details were assembled into a "details" dictionary, one could even think about having that definition in a separate response_actions_details/<RA-ID>_details.yml file. This would perfectly allow separation of a high-level "what needs to be done" view and a lower level "how would I do it in my environment" view.

Doing so would make it way easier to benefit from upstream RE&CT repository updates, since merging into my own instance wouldn't cause too much pain as any custom details wouldn't be affected by upstream changes.

What do you think? Would it be worth to spend some efforts on that? Cheers, -XoF-