Active Remediation FAQ

Unique user-specific environmental scenarios will be supported at best effort and will require a discussion and approval from the Threat Response Engineering (TRE) team.

Given our operational processes and workflows, some modifications to either automations and/or our response may not be supported.

Active Remediation will be performed 24/7 with a combination of SOAR and EDR-provided remote response capabilities. Threats are prioritized based on severity and are acted on accordingly.

• High severity threats are contained with automation and are then reviewed, with additional actions taken as necessary by the Threat Response Engineering (TRE) team.

• Medium-severity threats are contained with automation during non-business hours and are then reviewed. Additional actions are taken as necessary during business hours by the TRE team.

Business hours are 6AM MT-6PM MT Monday through Friday, excluding holidays. Red Canary holidays are in line with US Federal holidays, for additional information contact your CSM.

Red Canary Active Remediation has no publicly shareable Service Level Agreements (SLAs) or Objectives (SLOs) due to threat severity and complexity differences. This approach enables Red Canary to deliver high-quality services at scale continuously.

Active Remediation supports:

• Carbon Black Response

• Carbon Black Cloud

• CrowdStrike

• Microsoft Defender for Endpoint

• Palo Alto Cortex XDR

• SentinelOne

Active Remediation supports:

• Windows

• MacOS

Active Remediation does not support Linux due to the following:

• Wide variety of of Linux distributions

• Response complexity and impact of 24/7 hands-on remediation without in-depth knowledge of the environment

• Operational importance of most Linux endpoints

All Red Canary portals include a Request Remediation button that is only unlocked for full Active Remediation users.

The Request Remediation button allows for on-demand requests for remediation on a published High or Medium severity threat. The purpose of this feature is to provide users with a mechanism for requesting additional support in instances where:

• Endpoints were previously not enrolled within a designated remediation group but now are, and the user would like support addressing the threat.

• Threats were acknowledged by the user, who then prompted remediation efforts for a variety of reasons, but now would like to reengage a Threat Response Engineering (TRE) team member for support.

• Threats that we were unable to remediate due to the host being offline. The Remediation summary will request that you utilize the Request Remediation button to notify the team when the host is back online.

When you click the Request Remediation button, our Active Remediation team will begin remediation efforts on the affected endpoint, adhering to the standard remediation practices outlined earlier in this document.

If you would like the Threat Response Engineering (TRE) team to respond to all threats during your engagement as if they are true threats, you do not need to notify us. Red Canary will treat these threats as legitimate threats and take the necessary remediation actions.

If you would like the TRE team to be aware of the engagement and respond differently to threats that are associated with the engagement, click Contact Us before the engagement begins and we can work with you to customize our response.

Four playbooks are automatically created when you enable any Active Remediation (AR) subscription:

• AR — Unsupported OS Detected

• AR — Malicious/Suspicious Threat has new IOC

• AR — Malicious/Suspicious Threat Published

• AR — Notes Added by Red Canary

If you no longer use the AR subscription, you may need to manually remove the AR templated playbooks. Click Disconnect on the playbook to disconnect but not delete the playbook.

Alternatively, to remove a playbook’s association to a trigger, click the playbook, and click Delete from the left-hand menu.

The Threat Response Engineering (TRE) team works within the security controls already in place for customers, such as Conditional Access Policies (CAPs) and Multi-Factor Authentication (MFA).

• CAPS: To accommodate CAPs and ensure our access is secure and efficient, Red Canary has a dedicated IP address that customers can use to configure their CAPs for AR access. This allows customers to maintain strict access controls without impeding the TRE team’s ability to perform its work. While the dedicated IP address is currently fixed, it may change over time. Any updates to the IP address or range will be promptly communicated to ensure uninterrupted operations. Please note that the exact IP address is only available upon request for security purposes.

• MFA: The Red Canary Threat Response Engineering (TRE) team uses Okta as its IDP for MFA. We maintain a dedicated RBAC group that exclusively includes our TRE team members. This group’s membership is synchronized with Azure, enabling customers to easily restrict access to only Red Canary TRE. By default, an Access Package will limit logins to Red Canary’s Azure tenant. However, this can be further refined to limit access specifically to the TRE team, providing granular control over who can access your data within our environment. To configure this control, follow the steps on Set Up Your Microsoft Entra ID Cross-Tenant Access.