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 ALERT-) 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 your or the Red Canary CIRT to review. Before we generate an event, the Red Canary platform determines if you or the CIRT 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 you or the Red Canary CIRT so that we do not investigate the same thing repeatedly.
The Investigation & Response Phase
Finally, you or the Red Canary CIRT investigate(s) 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 not a threat if all events are confirmed as false positives.
- The alert is marked as mitigated if the alert stated the underlying activity was blocked.
What states can an external 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 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.