The Red Canary Approach to Security Data and Threat Detection
- 19 Mar 2025
- 6 Minutes to read
- PDF
The Red Canary Approach to Security Data and Threat Detection
- Updated on 19 Mar 2025
- 6 Minutes to read
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
At Red Canary we believe security is paramount, so our only mission is to deliver accurate, complete, and timely threat detections to protect your organization. Over the years, our extensive experience in the Managed Detection and Response (MDR) space has taught us that a truly immense volume of security data must be screened to identify even a single actionable threat. We’ve learned to focus only on what really matters when it comes to finding actionable threats among all the noise.
This document explains how we target our threat-finding operations and gives some examples of the type of data we prioritize.
Our Approach to Security Data
Red Canary uses threat intelligence and our extensive security expertise to broadly understand the threat landscape. We then narrow our focus by characterizing the shape and sizes of attacks while also pinpointing artifacts left behind by adversaries.
Specifically, Red Canary concentrates on the portion of the attacker kill chain where early reconnaissance and full-blown compromise intersect across endpoint, identity, and cloud security.
This can include indications of activity relating to:
Ransomware
Business Email Compromise (BEC)
Post-exploitation
Webshells
Credential theft
Execution of known malware
Honey tokens
Suspicious cloud and identity activity
Creating Security Detection Analytics
Our focused approach to security data has a direct influence on how and why we create our security analytics, known as detectors.
Designed to focus on behaviors and patterns frequently used in malicious or suspicious activity, our detectors are crafted to identify threats using security data that can be most effectively leveraged to initiate an investigation. These detectors are carefully paired with a powerful suppression engine, which is able to rapidly minimize known benign activity. This allows Red Canary to surface high-confidence atomic data points called Investigative Leads.
To provide transparency into our detection capabilities, we give our customers access to detection analytics directly in the portal. This includes information about each detector and its threat detection purpose, giving visibility into our coverage.
Red Canary’s Shared Operating Model
At Red Canary, we see ourselves as a partner in protecting your organization from security threats. Alongside the expertise we provide with security detection analytics, we recognize there are certain types of data where customers are ultimately in the best position to investigate.
Examples of these types of data can include:
Custom alerts, where an organization’s team has the most context behind the need for certain alerting
Recommendations and configuration notices, where security tools may suggest action items for an organization
User-reported activity, where the organization may need to do individual follow-up with the reporter
The data Red Canary prioritizes for detection as well as data that is handled by customers as part of the shared operating model ultimately create the complete picture needed for full context.
FAQ
What is Red Canary’s opinion on network alerts and logs?
Network security tools such as firewalls, Software Gateways (SWGs), or Security Service Edge (SSE) solutions are valuable additions to a security stack, but the best signals in these logs for detecting compromise are redundant for customers with good detection and response coverage for identities and endpoints. Red Canary focuses primarily on getting telemetry directly from endpoint, cloud, and identity sources because those are the critical places where a threat starts and ends.
Why didn’t Red Canary investigate all of my data?
Not all security data is created equal in terms of detection value. In isolation, some security data simply does not provide the high value data points to detect or initiate an investigation.
Thanks to our platform-agnostic approach of providing high quality MDR across many security tools, Red Canary has extensive experience with various types of data. This in turn has made us experts when it comes to deciding what types of security data are best used to initiate an investigation.
Upon initial ingestion, data may not be investigated for one of the following reasons:
Criteria not met
These alerts, while potentially interesting, don’t meet our threshold for an investigation due to their severity and classification. This means that based on our expertise and experience, this particular alert is unlikely to present sufficient information or threat detection. Examples of these activities can include:
Vulnerability/port scanning: Programmatic, widespread scanning of an environment, with the absence of malicious follow on activity.
Configuration changes: Notices of a configuration change are typically highlighting that a configuration set by a tool or customer was done incorrectly, has changed, or some related activity occurs. In the absence of malicious follow on activity, this data is not an indication of malicious/suspicious behavior).
Recommendations provided by security tools: Recommendations commonly include observations made by a security tool based on a configuration, lack of coverage, etc. This data is not indicative of an active threat.
EICAR: These files are run to elicit a detection/alert from a security tool for testing purposes, without needing to initiate actual malicious activity. This activity isn’t indicative of an active threat, and as such we will not publish a Threat based on EICAR. To manually publish a test Threat, use RCCAR .
Custom alerts
We recognize that some organizations create and utilize custom alerts within their security tools. However, due to the highly variable nature of these custom rules and their unknown provenance and accuracy, we don’t investigate alerts generated from them.
User-reported activity
While user-reported activity can be valuable, their context and accuracy can vary significantly. As such, Red Canary does not investigate alerts created from user-reported activity when the alert itself doesn’t provide sufficient information about the reported activity.
Example of a common alert that won’t be investigated
Some alerts hone in on configuration changes that are ultimately informational in nature. Since these types of alerts, like in the sample below, are not indicative of an active threat, they’re not investigated.
{
"system": "Dragos Platform",
"id": "18419768",
"created_at": "2025-01-09T22:45:14Z",
"occurred_at": "2025-01-09T22:30:36Z",
"severity": "1",
"cef_severity": "2",
"original_severity": "",
"summary": "New IP Address as Source",
"source": "a3672e46-d78b-4f8c-a9e7-0ee059d92b05",
"content": "Asset 27041 seen as the IP source for the first time - [].",
"detection_quad": "Configuration",
"detector_id": "d7687212-62c7-44c6-809d-886a515c58d2",
"matched_rule_id": "3",
"reviewed": "False",
"type": "Communication",
"attack_tactic": "None",
"attack_technique": "None",
"asset_id": "",
"asset_ip": "",
"asset_hostname": "",
"asset_mac": "",
"asset_domain": "",
"src_asset_id": "27041",
"src_asset_ip": "[redacted]",
"src_asset_hostname": "",
"src_asset_mac": "",
"src_asset_domain": "",
"dst_asset_id": "",
"dst_asset_ip": "",
"dst_asset_hostname": "",
"dst_asset_mac": "",
"dst_asset_domain": ""
}Example of a custom alert that won’t be investigated
Here’s a sample of an alert that was created from a custom rule. In isolation, there’s no indicator as to the original intent of this custom alert. However, custom alerts are helpful datapoints for contextual information.
"behaviors": [
{
"device_id": "[redacted]",
"timestamp": "2025-02-11T06:37:43Z",
"template_instance_id": "55",
"behavior_id": "41004",
"filename": "chrome.exe",
"filepath": "\\Device\\HarddiskVolume3\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"alleged_filetype": "exe",
"cmdline": "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" ",
"scenario": "suspicious_activity",
"objective": "Falcon Detection Method",
"tactic": "Custom Intelligence",
"tactic_id": "CSTA0005",
"technique": "Indicator of Attack",
"technique_id": "CST0004",
"display_name": "CustomIOAWinLowest",
"description": "A process triggered an informational severity custom rule.",
"severity": 10,
"confidence": 100,
"ioc_type": "",
"ioc_value": "",
"ioc_source": "",
"ioc_description": "",
"user_name": "[redacted",
"user_id": "[redacted]",
"control_graph_id": "ctg:3782eb617e3a4ec3aad1ce611a1bc1cc:21483748663",
"triggering_process_graph_id": "pid:3782eb617e3a4ec3aad1ce611a1bc1cc:96161300135",
"sha256": "1d16a3292125398c2313d9c4fc81d6eb4e2fd02cfba496985d9aff444d84f841",
"md5": "0d03a2393a4e78475d291b84690d2637",
"parent_details": {
"parent_sha256": "b121d7f22ba12fd42e3663de08305654c289f64c7daead4a0047b7d88e366346",
"parent_md5": "0adea275061771555e05f5fd383ca4e1",
"parent_cmdline": "C:\\WINDOWS\\Explorer.EXE",
"parent_process_graph_id": "pid:3782eb617e3a4ec3aad1ce611a1bc1cc:95395426378"
},Example of a user-reported alert that won’t be investigated
This is an example of an alert that was created after a user reported suspicious activity. In this case, the alert has metadata about the reported activity, but there’s no indication as to what the potentially suspicious behavior or activity was.
"displayMessage": "User report suspicious activity",
"eventType": "user.account.report_suspicious_activity_by_enduser",
"outcome": {
"result": "SUCCESS",
"reason": null
},
"published": "2025-03-14T15:44:04.196Z",
"securityContext": {
"asNumber": 2711,
"asOrg": "spirit communications",
"isp": "spirit communications",
"domain": "[redacted]",
"isProxy": false
},
"severity": "WARN",
"debugContext": {
"debugData": {
"traceId": "d6c0267b-2bed-494d-a87c-408dc7e705ca",
"requestId": "dcfc1fb0091267f6426f8cdc74f432a3",
"suspiciousActivityEventId": "e39cdb5a-00df-11f0-9763-21b9f6309d3a",
"dtHash": "cdce2d820ef14074123ea6618872fd91071327fbd485ef3bb49b90eb900ded76",
"suspiciousActivityTimestamp": "2025-03-14T14:23:24.490Z",
"requestUri": "/api/internal/users/me/report-suspicious-activity",
"suspiciousActivityEventTransactionId": "unknown",
"suspiciousActivityEventType": "system.email.mfa_enroll_notification.sent_message",
"url": "/api/internal/users/me/report-suspicious-activity?i=eyJ6aXAiOiJERUYiLCJ2ZXIiOiIxIiwiZW5jIjoiQTI1NkdDTSIsImFsZyI6ImRpciJ9..b9qOH1ky5o6uVIDx.GBO02xDtvoUDLXKJyuQyyhmiItTr0XI3bS3mRgkW_X3HL7FfNWSkj6pJ6AJ-ASLQzA7fvRFt8y1jl83a-nar5t7h-fS8Nuai_JBTkTYFJpISPwfrQ2Uokb1cMoMENPCAtRk7luEdvcdi3DXFyA4lvsqrq4zeEBJ8OpuRQDgd3iH6P-mlfb823cz7jEcv-okijp05vrqlVWdAtuo.FrXqIicDCL9FDdbOAtYtYA"
}
},
"legacyEventType": "core.user.account.report_suspicious_activity_by_enduser",
"transaction": {
"type": "WEB",
"id": "dcfc1fb0091267f6426f8cdc74f432a3",
"detail": {
}How can I store compliance data that I don’t need investigated?
If you need to retain this data for compliance or other purposes, Red Canary provides cost-efficient storage in our Security Data Lake.
Was this article helpful?
