Approve actions before they run in

Take action on an asset to either make it do something or retrieve information from it. For example, you can create an action to use a firewall to block a particular IP address, request a list of VMs from a VMware ESXi server, or look up a file hash on VirusTotal.

Action approval is controlled at the asset level. You can assign an asset to one or more approvers. If someone takes action on that asset, all approvers must approve the action before it runs. If an asset has no approvers, or if the actions are read-only, all actions taken on it run immediately. A read-only action is an action that does not change anything on the device or application with which it is communicating. For example, a read-only action from a firewall obtains information from the firewall without doing anything to change the firewall.

Take action on assets

An asset doesn't need to have approvers. Approval is only required for actions that have a write component.

To start an action, perform the following steps:

1. From the Home menu, click Sources.
2. Select a label.
3. Select an event.
4. Click Analyst to make sure you are in analyst view.
5. Click Action.

For more information about how to assign approvers to assets, see Add and configure apps and assets to provide actions in in the Administer manual.

The following diagram describes the approval escalation path in :

Primary approvers

If an asset has primary approvers, the required number of approvers must approve the action within the action service level agreement (SLA) deadline. If any single primary approver denies the action, the action stops immediately and no further approvals are permitted.

Secondary approvers

If the minimum number of approvals by primary approvers isn't met within the SLA, but no one denied the action, it moves to secondary approvers and the action SLA clock starts over. For more information, see Configure the response times for service level agreements in the Administer manual.

Executive approvers

If the action isn't approved or denied within the secondary SLA, it moves to the executive approvers. Executive approvers have the same amount of time to approve the action. If they fail to act on it, it expires and doesn't run. For more information on Executive approvers, see Configure Executive approvers for a asset.

Run actions using the API

You can also run actions using a call to the phantom.act API. See act in the Python Playbook API Reference for manual. The reviewer parameter is optional. If you specify this parameter, the action doesn't run until a reviewer approves or denies it. A reviewer is an analyst or member of the security operations team who reviews and decides if the action is allowed to run. After the reviewer approves the action, the approval process begins.

The first reviewer to approve or deny the action determines whether it runs or not. If the SLA expires before any reviewer approves it, the action fails.

Delegate actions to other users

When an approver receives a notification to approve an action, they can delegate the approval to one or more users or roles. Those users must approve or deny the action within the remaining SLA period or it moves to the next level of approval.

If you delegate an action, you renounce your portion of the vote. All delegates must approve the action for it to count as a single vote from the original approver.

Delegation example

Users A, B, and C are primary approvers for an asset that requires two approvers. Users D and E are secondary approvers, and they all need to approve the action. Users F, G, H, and I also exist on the system. Someone takes an action on the asset and users A, B and C are notified.

If any two users approve the action within the SLA deadline, the action runs. Alternatively, user A might approve while user B delegates to users F and G. The action runs if users F and G both approve the action. While A approved directly, B effectively approved by being represented by F and G. The single-user veto still applies because users F or G can deny the action.

Alternatively, if users F or G don't approve but C does, the action runs because A and C make up the two approval votes needed.

A second level of delegation is allowed. When user B delegates to F and G, user F can then delegate to users H and I. The requirement that all delegates must approve still stands. To represent user B's original vote, G, H, and I must all approve. G has half a vote, and H and I each have a quarter of a vote.

Delegation restrictions

You can't delegate to other approvers that an action is currently waiting on. Primary approvers can delegate to secondary approvers, but not other primary approvers. You can delegate to primary approvers only once an action expires and moves to the secondary approvers.