Alerts are the notifications that security products send you. Some security products send alerts only when they identify threats that need immediate response. Other security products send alerts in purely informational situations. This article will cover the four phases of the alert lifecycle, Alert Workflow Rules, MDR threat investigation, and alert remediation.

Time to read: 10 minutes

What does Red Canary do with alerts?

Alerts within Red Canary follow a four phase process.

Phase 1: Ingestion

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

Phase 2: Enrichment

With your telemetry ingested, we 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 Red Canary takes 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, we evaluate the Alert Workflow Rules and apply 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, we 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.

The following security platforms support state and comment syncing:

• Elastic Security
• Microsoft Defender
• Crowdstrike Falcon Insight: EDR

Phase 3: Correlation

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 intuitively looks at 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

We determine which endpoints were involved in the alert. This is a critical step for narrowing down your 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 we discover 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, we determine 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.

Phase 4: Investigation

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 Threat Investigation

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 prioritization of alerts. In addition, this process reduces the number of alerts you need to review and highlights the highest priority threats in your environment. Learn more about supported alert sources for threat investigation.

Red Canary assigns the alert a priority based on the threat investigation results.

Priorities	Description
Likely a Threat	Red Canary has determined the alert to be highly suspicious and could result in a threat after investigation.
Suspicious, May be a Threat	Red Canary has determined the alert is suspicious but has the potential to be known as normal behavior unique to your environment. Customer review and feedback is needed to further improve MDR alerting capabilities.
Suspicious, Likely Benign	Red Canary has determined that the alert is likely not a threat, but the behavior should be reviewed by the customer for confirmation.
Likely Not a Threat	Red Canary has determined that the alert is non-threatening.

 

Once our analysts specify a priority and add additional analysis commentary to the alert, it’s assigned to you for review and remediation actions.

Customer Alert Investigation

Security alert data from source platforms that aren’t part of the MDR service are placed in your triage queue. You can investigate the alert data directly in Red Canary and have your analysts specify priorities, add notes, and assign remediation actions to members of your team.

Phase 5: Remediation

Once security alert data has been reviewed and analyzed, 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, assigned to a reviewer, or given a priority. 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 Getting started with automation.

How long are external alerts retained?

External alerts associated with a tipoff or an event are retained indefinitely. External alerts not associated with an event are retained for 1 year.