Understand the Alerts Lifecycle

The first step is the ingestion phase, where Red Canary ingests all of the security alert data from the source platform you have configured with us. We normalize the data and extract key data points in order to get the most out of your telemetry. You can see these alerts within Red Canary. 

With your telemetry ingested, Red Canary can parse additional Alert Workflow Rules to help look for specific triggers within an alert.

Alert workflow rules

Red Canary's Alert Workflow Rules let you create custom ingest rules and define the actions we take in response to alerts. You can filter alert data as it comes into Red Canary and make updates to the actions you want taken when alerts are detected. From here, Red Canary evaluates the Alert Workflow Rules and applies the designated changes when an alert matches the specified criteria.

By using the synchronization capability via API in the third-party source platform, Red Canary can deliver updates on the alerts to your third-party source platform. This allows us to provide comments and status changes for these alerts. In addition, Red Canary can close alerts that are determined to be non-threatening. This functionality isn’t available for alert sources that don’t support state synchronization and auto-commenting functionalities. In addition, for these features to work, there must be a built connection between Red Canary and your third-party security platform.

Review the list of alert sources for which Red Canary supports state and comment synchronization.

What states can an external alert have?

Alerts have a state that changes during Red Canary's validation of the alert.

Some of these states are terminal (examples include Mitigated or Confirmed Threat), while others are temporary states while an alert is mid-process (an example includes Pending Review). 

• Confirmed Threat—The activity identified by the alert was confirmed as threatening by your team or the Red Canary CIRT (and may be associated with a detection).

• Mitigated—The alert indicated that the potentially threatening activity was prevented by a security control.

• Not a Threat—The alert was deemed non-threatening by your team or the Red Canary CIRT.

• Integration Testing—The alert was ingested during the integration testing of the alert source.

• Pending Your Review—The Alert has been ingested and is awaiting your investigation.

• Pending Red Canary Review—The Alert has been ingested and is awaiting investigation by Red Canary.

• Attempting Correlation—The alert is being correlated to endpoint, identity and process data.

Analysis

Once Red Canary receives an alert, we extract four key pieces of information:

• Correlation points describe the parts of an alert that a security engineer uses to correlate the alert to other security data. These are the pieces of data that every security engineer analyzes when they review an alert (hostnames, IP addresses, and binary MD5s/hashes).

• Analysis context is the additional context about the alert provided by the security product. Examples of these vary across products. Network security products may provide net flow metadata, sandboxes may provide binary behavioral context, and endpoint security products may provide information such as Office document macro metadata.

• Reported severity is the severity of the alert as reported by the alert itself. Red Canary then labels this information with a severity level of high, medium, low, informational, or unknown.

• Reported classification is the class or type of alert that is reported by the alert. This classification varies across security products and is best described as the headline that the alert might present.

Identity correlation

Using the identity data available in the alert, Red Canary looks for matches in identity records in the Red Canary system. Identity data includes usernames, email addresses, user IDs, names of personnel, and phone numbers. If we discover a new identity, we record and store that identity for future correlations.

Endpoint correlation

Red Canary determines which endpoints were involved in the alert. This is a critical step for narrowing down the investigation to the right set of endpoints.

This step is significant because most alerts come from security products that have a very limited ability to identify an endpoint involved in an alert. Alerts will often report IP addresses (which change frequently), hostnames (which aren’t guaranteed to be unique), and user accounts.

Red Canary's goal during endpoint correlation is to identify the specific number of endpoints that are involved in the alert to determine the scope and potential severity of the threat. This is done by taking endpoint-related correlation points that are extracted from the alert and correlating them to the endpoint metadata we have from monitoring your systems. If Red Canary discovers a new endpoint during correlation, we record and store that endpoint for future correlations.

Process correlation

With a set of endpoints that are likely involved in the alert, Red Canary determines what endpoint activity led to the alert. This process is performed using the alert's correlation points and can result in multiple correlated processes that are suspect.

Each correlated process becomes an event for the Red Canary Cyber Incident Response Team (CIRT) to review. Before we generate an event for the CIRT, Red Canary determines if we have already analyzed this behavior and deemed it to be non-threatening, in which case it is suppressed. Suppression criteria are the product of past investigations performed by our CIRT and are used so we don’t investigate the same event repeatedly. Learn more about suppression on the Red Canary blog.

Investigations of aggregated security alerts are performed either by you or between you and Red Canary depending on the service you have. RedCanary aggregates all of the security alert data from your various sources and normalizes and correlates these for investigation. For specific security products, Red Canary provides you with our MDR service to manage your alert analysis.

Red Canary MDR

When you have the Red Canary MDR service, we support the triage and analysis of alerts across identity, network, and SaaS security products. This information provides you with extended visibility and the status of alerts. In addition, this process reduces the number of alerts you need to review. Learn more about supported alert sources for threat investigation.

Once our analysts specify an alert status and add additional analysis commentary to the alert, it’s assigned to you for review and remediation actions. For more information, please see Post-Triage, Red Canary Final Alert States.

Customer Alert Investigation

Security alert data from source platforms that aren’t part of the MDR service, including custom detectors you may create in your source platform, are placed in your triage queue. Please note that Red Canary does not review these. You can investigate the alert data directly in Red Canary and have your analysts specify alert status, add notes, and assign remediation actions to members of your team.

By User

Once security alert data has been reviewed and analyzed, you should address the identified threats for remediation. 

Use automated playbooks to facilitate your remediation process. Playbooks take actions based on when alerts are placed in a specific status, or assigned to a reviewer. When triggered, the playbook performs automated actions in Red Canary or in third party systems for notifications, ticketing, or remediation actions.

For more detailed information about playbooks, see Automation.

Red Canary Active Remediation

If you subscribe to the Red Canary Active Remediation add-on to the Red Canary platform, Red Canary threat hunters will respond to high- and medium-severity threats identified by the Red Canary platform by taking remedial action on your covered endpoints via the tools available in your supported EDR software.

After subscribing, the Red Canary team will work with you to organize your covered endpoints into groups with your instructions as to how each endpoint should be handled in the event of a threat.

External alerts associated with a tipoff or an event are retained indefinitely. External alerts not associated with an event are retained for 90 days. For more information regarding retention policies, see Data Retention Policy.