Configuring Proactive Response Actions Using Tags
The following shows how you can configure Proactive Response isolation and Restoration actions policy using tags.
Note
The endpoint based playbook examples apply to all of your assets—both existing assets and any new assets added later—that have the Taegis Agent installed. The same is true for any other playbooks you create for other endpoints or integrations.
You can indicate the specific assets you want Proactive Response Isolation and Restoration Actions to be taken on – or conversely, not taken on – using tags added to the tag KEY field of those specific assets. For the purposes of ManagedXDR, you can use any asset tagging schema that is most effective for your needs; however, ensure that you consider the following as you define your asset management and tagging policies: as new assets are added or changed in your environment, ongoing asset management and tagging are an important part of ensuring that Proactive Response Actions are handled properly as part of the ManagedXDR service. This is your responsibility, as our analysts do not have knowledge of your intent with new assets.
There are two general types of policies to consider, as explained below:
Default Opt-in Policy ⫘
If for most of your assets you want Proactive Response Isolation and Restoration Actions taken (except for any specified set of assets you do not want actions taken), the default policy is likely best policy for you. This policy provides Proactive Response Actions for the majority of your assets while allowing the exclusion of a small number of specified assets.
With this approach, MXDR analysts will take Proactive Response Isolation and Restoration Actions unless the asset is explicitly tagged as NOT APPROVED for Proactive Response Actions. You can use any type or number of tags that you prefer. For example:
- All executive laptop assets use tag
VIP_no_responsein the tag KEY field - All critical infrastructure assets use tag
critical_no_responsein the tag KEY field
These example tags specify that no Proactive Response Actions are taken for VIP or critical infrastructure assets without your explicit permission. You must tag all assets you do not want Proactive Response Isolation and Restoration Actions for. Use the Trigger Filter field in the associated playbook to ensure that proactive actions are not conducted for the specific assets that have the tag(s) you created, as detailed in Tag Assets to Not Approve Proactive Response Isolation and Restoration Actions.
Important
With this policy, Proactive Response Isolation and Restoration Actions are conducted on all assets unless they are tagged. The advantage of this policy is that Proactive Response Actions are taken on new assets by default, even if you do not tag them or forget to tag them.
Example: Tag Assets to Not Approve Proactive Response Isolation and Restoration Actions ⫘
Configure this policy similarly to the Host Isolation and Restoration Playbook Configuration for the Taegis Agent, but update the trigger filter to check for the absence of a tag you created for assets you do not want Proactive Response Actions for, such as the example VIP_no_response and critical_no_response tags:
Trigger Filter: inputs.asset.endpointType == 'ENDPOINT_TAEGIS' && !('VIP_no_response' in assetTags(inputs)) && !('critical_no_response' in assetTags(inputs))
You must add the tag(s) specified in the filter to the tag KEY field on all associated assets you do not want Proactive Response Actions taken for.
Note
If Secureworks determines that there is a critical threat to an asset that you previously tagged as NOT APPROVED, we contact you by telephone. After obtaining your permission, Secureworks then removes the tag on that specific asset and perform the required action (e.g. MXDR_ISOLATE). After you finish remediation activities, you may add the tag back to that asset if desired.
Default Opt-out Policy ⫘
The default opt-out policy is the recommended policy if for most of your assets you do not want Proactive Response Actions except for specific assets you want actions taken on.
With this approach, ManagedXDR analysts do not take Proactive Response Actions unless the asset is explicitly tagged as approved for Proactive Response Actions. You must tag all assets you do want proactive actions to be taken on. You can use any type or number of tags that you want. For example:
- Add the tag
response_approvedin the tag KEY field of assets you want MXDR analysts to take Proactive Response Actions on.
Then use the Trigger Filter field in the associated playbook to ensure that proactive actions are only taken for the specific assets that have the tag(s) you created, as detailed in Tag Assets to Approve Proactive Response Actions.
Important
With this policy, Proactive Response Actions are not conducted on any asset without a tag. The advantage of this is Proactive Response Actions are not taken on new assets by default in case you forget to tag them or if there is a delay between when new assets are operationalized and when they are tagged.
Example: Tag Assets to Approve Proactive Response Actions ⫘
Configure this policy the same as Host Isolation and Restoration Playbook Configuration for the Taegis Agent, but update the Trigger Filter to check for the presence of a tag you created for assets you do want Proactive Response Actions for, such as the example response_approved tag:
Trigger Filter: inputs.asset.endpointType == 'ENDPOINT_TAEGIS' && ('response_approved' in assetTags(inputs))
You must add the tag(s) specified in the filter to the tag KEY field on all associated assets you do want Proactive Response Actions taken on.
Endpoint Tagging Playbook ⫘
To find and tag multiple endpoints (i.e., assets), you can use the Endpoint Tagging playbook located within the Automations → Playbooks → Templates area of your XDR instance. The instructions for completing the playbook are within the playbook in your XDR instance.
Endpoint Tagging Playbook
Note
Each playbook has built-in documentation that walks through the steps to create a new playbook. Select Documentation from a playbook template or configured playbook in XDR to open this in a new tab and follow the guidance there.