This article is part of a walkthrough of getting started with Red Canary:

1. Collecting endpoint telemetry
2. Collecting external alerts
3. Detecting potential threats (performed by Red Canary)
4. Investigating potential threats (performed by Red Canary)
5. Responding to confirmed threats

Once endpoint telemetry is flowing to Red Canary (and optionally accompanied by external alerts), Red Canary’s detection pipeline kicks in.

Red Canary’s detection is designed to identify as many possible types of threats that adversaries may use against your organization. This broad approach results in a lot of false positives for the Red Canary team to investigate, but it delivers the best results to you.

As Red Canary processes the telemetry and alerts collected from your endpoints and security products, any threat intelligence or analytics that match result in the creation of a potentially threatening “event” that goes to the Red Canary Cyber Incident Response Team (CIRT) for investigation.

Onboarding and tuning detection

Unlike other security products, Red Canary does not require you to define your own detection rules and indicators of compromise (IOC) to get extremely effective results. From day one, you get the benefits of years of Red Canary detection engineering for hundreds of other customers.

Understanding detection coverage

Transparency is critical to understanding how Red Canary fits into your security stack. You need to know where Red Canary provides coverage and where we do not, and we strive to make that information easy to find.

Red Canary’s detection coverage is most easily viewed in an ATT&CK heatmap. From there, you can drill into a specific technique and learn more about whether Red Canary has coverage for it.

You can also view and filter a complete list of detection analytics in the Analytics & Intelligence view:

Next, learn about how Red Canary investigates these potential threats and confirms true positives.