Skip to main content
Go to Red Canary Documentation
Red Canary Support

Best Practices for Managing Endpoints in Red Canary

  • Updated .

Table of Contents

  • Reviewing and Monitoring Endpoints
    • Checking Endpoint Activity
    • Endpoint Retention Policy
    • Managing Offline Endpoints
  • Decommissioning Endpoints
    • When and Why to Decommission
    • How to Decommission
    • Handling Decommissioned Endpoints
  • Sensor Management
    • Endpoint Isolation
    • Best Practices When Uninstalling Sensors

Reviewing and Monitoring Endpoints

From the main screen of your Red Canary console, you are able to see the endpoints monitored graph. This provides an overview of the monitored endpoints over time, as well as a quick link to any endpoints that are currently not sending telemetry.

2023-10-12_12-58-48.png

Checking Endpoint Activity

Navigate to the endpoints page from the Red Canary console by clicking the "Endpoints" tab on the left hand navigation pane.

For each endpoint listed, there are three columns that represent different activity types:

2023-10-12_12-59-47.png

First Seen: This is when the endpoint was first seen by Red Canary through sensor installation or discovery.

Last Checkin: This is when the endpoint last communicated with Red Canary or its EDR platform.

Last Activity: This is the last time the endpoint sync received telemetry from the endpoint. If this value is "Unknown" then the endpoint has never sent telemetry. 

Note: Last Checkin and Last Activity values are updated by an endpoint sync job that runs approximately every 30 minutes and do not represent connectivity in real-time.

Endpoint Retention Policy

Any endpoint record associated with a published Threat, Alert, or Analyzed Event are kept on the Endpoints page indefinitely. All other endpoints are displayed until their Last Checkin and Last Activity times both exceed one year. See Red Canary's Data Retention Policy for more information.

Managing Offline Endpoints

It is common for the Last Activity time for workstations to be outdated over the weekends, as employees often power down their devices, resulting in no new telemetry being collected. During the week, if an endpoint or a group of endpoints doesn’t send telemetry for three consecutive days, a telemetry health check ticket is automatically generated for support.

For endpoints that are infrequently online, like those used for testing, it's recommended to bring these online a minimum of every three days to prevent them from being reported as uncommunicative by Red Canary. Endpoints inactive for more than three or more days, such as assets assigned to users on extended leave, will be included in the uncommunicative workstations report as part of Red Canary's daily summary.

To address endpoints such as this, or those taken offline indefinitely, Red Canary provides the ability to decommission and recommission endpoints.

Decommissioning Endpoints

When and Why to Decommission

Endpoints should generally be decommissioned in Red Canary when monitoring and reporting of an endpoint is no longer required, such as a server removed from service or deactivated machine. Maintaining an accurate endpoint inventory through the use of decommissioning is important to ensure the accuracy and usefulness of Red Canary reporting, asset filtering, and automation. This process remove decommissioned endpoints from most reports, emails, and other views.

Aside from endpoint lifecycle management, there may be other real-world scenarios that call for the use of decommissioning, like addressing duplicated endpoint records.

Depending on the EDR vendor, an endpoint may be issued a new Sensor ID by the platform if the sensor software is reinstalled or reregistered. When this occurs, a new endpoint record will be created in the Red Canary Portal with a new First Seen date. Since endpoint telemetry is associated to endpoints based on the Sensor ID, the Last Checkin and Activity times will stop incrementing on the stale endpoint record and the incoming data will be associated with the new record.

Duplicate records can be found by searching the relevant hostname on the Endpoints page. You can use filters to understand and review endpoint connections to Red Canary.

How to Decommission

Endpoints can be decommissioned individually or in bulk using any of the following methods.

Manual Decommissioning in Red Canary

Endpoints can be manually decommissioned from the Endpoints page or the endpoint record's details page using the Decommission button.

Using Red Canary API for Decommission

The REST API can be used to decommission one or more endpoints at a time.

Automating the Decommission Process

Red Canary automation can be leverage to automatically decommission endpoints that exceed a specified Last Checkin date in number of days.

Handling Decommissioned Endpoints

Notifications for Restored Communication

In the event Red Canary receives data for a previously decommissioned endpoint, automation can be created to notify users, who can subsequently reinstate endpoints as needed. To configure this automation, please see this support article.

Reinstating Decommissioned Endpoints

Decommissioning is a reversible process, though it does require user intervention. Endpoints can be reinstated by navigating to the individual endpoint's record then clicking the "reinstate it" hyperlink from the banner. Red Canary's REST API can also be used to reinstate endpoints individually or in bulk.

Sensor Management

Endpoint Isolation

Endpoints can be isolated by their EDR software through the Red Canary Portal by users with the Responder role or using automation. To be notified any time an endpoint is isolated, refer to the guidance from this support article.

Best Practices When Uninstalling Sensors

Decommissioning in the Red Canary Portal will not remove the sensor software from the associated machine. Sensors should be uninstalled from the integrated EDR's management console, in conjunction with decommissioning in Red Canary, to ensure proper endpoint hygiene.