External alerts are the alerts from your security products, services, cloud provider, etc. These alerts are often difficult to investigate conclusively because they only describe part of the story of what happened.

Red Canary takes these alerts, correlates them together, and—most importantly—determines if there was any activity on your endpoints that corroborates the activity described by the alert. This process of “alert validation” oftentimes dramatically reduces the number of alerts your team needs to review.

Each alert is given an identifier (starting with EA-) that uniquely identifies the alert throughout Red Canary.

What process do alerts go through?

The process starts with alerts being collected through various Red Canary collectors and APIs that integrate with your alert sources.

External alerts follow the process that a great security team would do with every alert they receive from a security product. Through our unique blend of technology and CIRT security engineers, we are able to perform this process with tremendous consistency and quality for every alert we process.

The Analysis Phase

Once Red Canary receives an alert, the platform extracts four key pieces of information:

  • Correlation points describe the parts of an alert that a security engineer would use 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, binary MD5s/hashes, etc.
  • Analysis context is the additional context about the alert provided by the security product. Examples of these vary tremendously across products; network security products may provide netflow-like metadata, sandboxes may provide binary behavioral context, and endpoint security products might provide information such as Office document macro metadata.
  • Reported severity is the severity of the alert as reported by the alert itself, mapped to the Red Canary standard severities high, medium, low, unknown, and informational.
  • Reported classification is the "class" or "type" of the alert, also as reported by the alert. This varies widely across security products and is best described as the "headline" the alert might present.

The Endpoint Correlation Phase

The next step of handling an alert is to 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 also nontrivial because most alerts come from network-based security products, and those products have a very limited ability to concretely identify an endpoint involved in an alert. Alerts will often report IP addresses (which change frequently), hostnames (which are not guaranteed to be unique), MAC addresses (commonly reused on VDI systems), etc.

Red Canary's goal during endpoint correlation is to find the smallest number of endpoints that are most likely to be involved in the alert. This is done by taking any endpoint-related correlation points extracted from the alert and correlating them to endpoint metadata we have from monitoring your systems.

The Process Correlation Phase

Now that we have a set of endpoints that are likely involved in the alert, we need to determine what endpoint activity led to the alert. This correlation to a process is performed using the alert's correlation points and can occasionally result in multiple correlated processes that are all suspect.

Each correlated process becomes an event for the Red Canary CIRT to review. Before we generate an event for the CIRT, the Red Canary platform 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 so that we do not investigate the same thing repeatedly (Learn more about suppression on the Red Canary blog.)

The Investigation & Response Phase

Finally, the Red Canary CIRT investigates each Event resulting from the process correlation phase. This investigation can result in one of several outcomes:

  • The alert becomes a confirmed threat if any Event is confirmed as threatening and published as a Detection.
  • The alert becomes a false positive if all Events are confirmed as false positives.
  • The alert is marked as activity blocked if the alert stated the underlying activity was blocked.

What states can an alert have?

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

Some of these validation states are terminal (examples include False Positive or Confirmed Threat), while others are temporary states while an alert is mid-process (an example includes Pending Review). Other states such as Uncorrelatable and Inconclusive become terminal states once we exhaust our attempted correlations after two days.

  • Activity Blocked is used when investigation showed that the activity identified by the alert was prevented by a security control.
  • Uncorrelatable means the alert could not be correlated to any monitored endpoints or activity in your environment.
  • Inconclusive alerts could not be correlated to any processes or activity occurring on the associated endpoint.
  • Alerts that are Pending Review are still undergoing correlation to endpoints and processes and being investigated.
  • False Positive alerts are those deemed non-threatening by the Red Canary CIRT after investigation.
  • Confirmed Threat alerts were confirmed as threatening by Red Canary and resulted in a dDetection.
  • Integration Testing alerts were ingested during the integration testing of the alert source.

What happens if an alert doesn’t correlate to an endpoint?

Alerts that fail to correlate to any endpoint are Uncorrelatable. This can happen for several reasons:

  • The alert may not have included any correlation points that can be used to identify the involved endpoints. We perform QA checks on alerts without these device correlation points to adjust our parsing logic whenever needed.
  • The alert may be associated with a device that is not protected by Red Canary (mobile devices, unmonitored endpoints, etc.). In these situations, it is critical that you know if the endpoint is unintentionally unprotected so that you can deploy sensors if so.

If we extracted a device IP address correlation point from the alert, we check to see if other endpoints we are monitoring are within the same /16 and /24 CIDR blocks. If so, that often means the device is unintentionally unprotected.

If we extracted a device MAC address correlation point from the alert, we look up the manufacturer of the hardware and present that information. It is usually easy to see that the device is a piece of network hardware, VOIP system, Android phone, or other device type that is intentionally unprotected by Red Canary.

To have the greatest chance of correlating an alert to endpoints, we retry this correlation every 30 minutes for two days.

What happens if an alert doesn’t correlate to a process?

Alerts that fail to correlate to processes are Inconclusive, meaning that there is no correlated endpoint activity for a CIRT security engineer to review to determine if the alert is a true or false positive. This can happen for several reasons:

  • The alert may not have included any correlation points that can be used to identify the processes that caused the alert to be triggered.
  • Your endpoint data collector does not collect detailed enough telemetry to enable the correlation. For example, many EDR systems do not collect complete network telemetry, so some network-based alerts will not correlate.

To have the greatest chance of correlating an alert to endpoints, we retry this correlation every 30 minutes for two days.

Did this answer your question?