Security Testing

• User teams are not obligated to inform Red Canary of a future penetration test but may choose to do so.

• User teams should not use the Request Remediation button to notify the team for testing activities. 

  • If a specific question is to be tracked and answered during regular business hours, please use the Contact Us button on the Threat.

• If a Hands-On Response to testing is required, the Threat Response Engineering team will take all actions available.

  • These actions include, but are not limited to, isolation, persistence removal, binary and script deletion, domain banning, process termination, and escalation to the user team.

  • Any recommendations made by the Threat Response Engineering team must be followed. Failure to do so results in the Threat Response Engineering team taking a Hands-Off Response approach, given that the response no longer mirrors a real scenario.

Red Canary’s Threat Response Engineering and the user’s teams respond to each Threat as if it were a real adversary.

With the Hands-On Response, it is up to the user team to determine if you wish to inform us of an engagement beforehand. You do not have to share any additional information (besides confirmation that the activity is a test and not a real adversary). 

The Hands-On Response is chosen by Red Canary users who want to test Red Canary’s services and do not want to notify us or share information that might not be available if the tests were a real adversary. If aspects of the test warrant deeper investigation after the fact, telemetry may roll off in the EDR before the team can review it. 

For example, the default retention periods for raw telemetry are:

• Carbon Black Cloud: 30 days

• Carbon Black Response: (varies)

• CrowdStrike: 7 days

• Microsoft Defender for Endpoint: 30 days

• Palo Alto Cortex: 30 days

• SentinelOne: 14 days

The Hands-On Response method of engagement can produce:

• Investigation into why the activity was handled the way that it was by Red Canary 

• Lessons learned and identification of gaps in user incident response processes

To be successful, the above outputs require:

• Rapid response by the user team to perform any actions recommended by the Threat Response Engineering team

• Collaboration between Threat Response Engineering, Detection Engineering, Threat Hunting, and user team

• A list of any concerns or opportunities for improvement:

  • Potentially missed remediation activity

  • Capability development

  • Process and procedure improvement for the user team

Additional considerations for the Hands-On Response method:

• Active Remediation automations must be in an active and unaltered state. 

• Threat Response Engineering will take all applicable and available actions.

  • These actions include but are not limited to, isolation, removal of persistence, deletion of binaries and scripts, banning of domains, termination of processes, and escalation to the user team.

    • These actions likely result in disruption of the tester and engagement. Similarly, operationally required resources may become inoperable due to isolation. 

• User teams must promptly follow all recommendations provided by Threat Response Engineering.

  • This helps ensure the engagement mirrors a real-world scenario. 

  • Failure to act on Threat Response Engineering recommendations, such as credential resets, allows the tester to continue, as remediation will never be complete.

    • Isolation must remain in place until remediation actions are completed.

Red Canary’s Threat Response Engineering team does not respond to Threats on endpoints in scope for testing.

With the Hands-Off Response method, the user team provides Red Canary with advanced notice of the testing. The user team may share as much or as little as they want about the test details. During the test, little or no information is shared with Red Canary (besides confirmation that the activity is testing and not a real adversary). 

This method is frequently chosen by Red Canary user teams who would like to balance testing Red Canary’s services (Detection efficacy), limiting hindering tester efforts, providing notice to avoid late-night calls about threats, and getting advice for configuring Remediate Sensor Groups to prevent service outages that could result from the testing. The tradeoff is that Red Canary’s Threat Response Engineering team will take no action against Threats. 

The Hands-Off Response method can produce:

• Process and procedure improvement for the user team

• Opportunities for new detector development

To be successful, the above outputs require:

• Advanced notification of intent to test

• Removal of hosts from Remediate Sensor Groups or change in Sensor Group naming conventions to omit the word Remediate

• Collaboration between Threat Response Engineering, Detection Engineering, Threat Hunting, and user team

Additional considerations for the Hands-Off Response method:

• Legitimate Threats that occur during testing will not automatically notify or be acted upon by the Threat Response Engineering Team.

  • The responsibility to notify the Threat Response Engineering team of legitimate Threats falls on the user during testing. This can be achieved by leveraging the Request Remediation button. For more information, see What is the Request Remediation button in my portal?