Threat Detection and Response (TDR): How It Works

Threat detection and response (TDR) is the work of spotting suspicious activity across endpoints, cloud, identity, and SaaS, investigating it to a verdict, and containing what turns out to be real. A GuardDuty finding on an IAM role, an Okta new-device sign-in, or an EDR PowerShell detection still needs logs and business context before SecOps can tell an intrusion from legitimate work.

CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time, the time an intruder needs to start moving laterally, at 29 minutes in 2025, with the fastest observed at 27 seconds. A detection that fires inside that window but waits in a queue may leave an attacker time to move before investigation begins.

TL;DR:

• Every detection method trades precision for coverage, and signatures, behavioral analytics, anomaly models, and threat intel each miss a different class of attack.
• Each domain breaks differently: attackers disable endpoint sensors, cloud logging coverage and retention vary by event type, and identity and SaaS abuse can resemble legitimate activity.
• A single alert is usually ambiguous on its own, because the verdict depends on context the alert does not carry, such as approved change windows and earlier investigation outcomes.
• Measure a TDR program by verdicts and resolutions, because ATT&CK heatmaps and alert counts mostly track activity.

How the Four Threat Detection Methods Work, and Where Each Fails

The four methods overlap in practice: threat intelligence feeds signatures and behavioral analytics, and behavioral detection can use rules, statistical models, or both. SpecterOps' detection spectrum model, published in 2020, places any of them on a spectrum from precise to broad. Precise detections carry a high propensity for false negatives: a rule that alerts on the Invoke-Kerberoast function misses Kerberoasting done any other way. Broad detections, such as any connection to a domain controller on port 88, create a triage burden heavy enough to swamp the alert queue.

1. Signature-Based Detection

Signatures compare observed events against patterns that correspond to known attacks. YARA matches strings and binary patterns in files; Sigma matches log fields such as process names, command lines, and registry keys. NIST's 2007 guide to intrusion detection, SP 800-94, notes that signatures typically recognize known events better than anomaly methods.

Simple signature matching cannot track state across complex communications and misses attacks made of multiple events when no single event looks malicious. Detection engines often pair signatures with stateful analysis to cover that gap. Packing, encryption, and polymorphism can evade static signatures that depend on the original bytes. A Sigma rule also detects nothing when the relevant systems never logged the events.

2. Behavioral (TTP-Based) Detection

Behavioral detection looks for actions tied to attacker techniques, and many analytics link individual telemetry records and maintain state to do it. In Red Canary's detection validation example, a process downloads a file, writes it to disk, and executes it, and the analytic fires only when those records are linked. In the cloud, MITRE's DET0078 strategy chains anomalous API calls with an authentication-context shift: a stolen token followed by RunInstances, CreateUser, or PutRolePolicy, with tunable checks for unexpected user agents such as boto3 or azcopy.

Behavioral rules inherit an ambiguity problem: many ATT&CK techniques have observable characteristics that cannot determine intent. Elastic's InfoSec team ran into this when it expanded its alert packages to more data sources: benign anomalies such as an API token used once a month left its analysts overwhelmed by false positives.

3. Anomaly and Statistical Detection

Anomaly detection builds a profile of normal over days or weeks and alerts on significant deviation. NIST's example is a profile of normal web bandwidth that triggers an alert when traffic runs well above it. A baseline can also absorb malicious activity if the attack is already running while the profile is built.

Anomaly detection has traditionally produced high false-positive rates and does not always explain why something was flagged, a problem MITRE described in its 2019 TTP-based hunting paper. Insiders using only authorized tools may generate no anomaly at all, one of the core difficulties of insider threat detection.

4. Threat-Intelligence-Driven Detection

David Bianco's Pyramid of Pain, first published in 2013, ranks indicators by how hard they are for an attacker to change: hashes are trivial, IPs easy, domains simple, and TTPs tough. Low-level indicators like hashes and IPs are also often detected only after adversaries have already used them in other breaches.

Indicators also decay quickly. Censys measured a median lifespan of five days for the Cobalt Strike C2 servers it observed. Feeds often keep indicators far longer: Elastic's ThreatQ integration falls back to a 90-day expiration, and in the CrowdStrike console IOC expiration is off by default, so some indicators may never age out.

Where Detection Breaks Across Endpoint, Cloud, Identity, and SaaS

In Unit 42's 2026 incident response caseload, 87% of intrusions involved activity across multiple attack surfaces.

1. Endpoint: The Sensor Is a Target

ESET counted almost 90 EDR killer tools in active use as of March 2026, most of them abusing vulnerable drivers. The driverless EDR-Freeze stays fully in user mode, so detections built only around driver loads miss it.

Once the sensor is silenced, network, identity, and cloud telemetry become the record of what the attacker did next. Edge devices typically lack standard telemetry, and Mandiant's M-Trends 2026 recommends network traffic analysis for those appliances.

2. Cloud: Partial Logs and Findings Without a Verdict

AWS GuardDuty, when enabled, automatically monitors CloudTrail management events, VPC flow logs, and DNS query logs, while EKS audit logs, S3 data events, and Runtime Monitoring are separate protection plans. GuardDuty extracts the fields it needs and then discards its own copy of the logs. Raw logs for cloud incident response have to be retained separately in CloudTrail and the other logging services.

In GCP, Data Access audit logs are disabled by default for every service except BigQuery, and the iamcredentials methods attackers use to mint tokens, GenerateAccessToken and SignJwt, appear only in those logs.

Cloud findings also tend to arrive without a verdict. Microsoft's ARM_AnomalousServiceOperation.PrivilegeEscalation alert carries Informational severity, and its description concedes "this activity might be legitimate." API traffic using a compromised token is logged as legitimate traffic from the user or service account it belongs to.

Short-lived infrastructure adds to the problem. Sysdig's 2025 data shows 60% of containers live for 60 seconds or less, and nothing in the logs necessarily ties an S3 read to the container process that made it.

3. Identity: The Signal Is a Pattern, the Verdict Lives Elsewhere

In Sophos's 2026 Active Adversary Report, 67% of incidents traced back to identity attacks. Identity threat detection starts with patterns like new devices and unfamiliar locations, but reaching a verdict takes context identity platforms often lack: HR status, role, travel, and device inventory.

4. SaaS: Valid Credentials and Tokens Can Hide Unauthorized Access

SaaS abuse often generates no anomaly at the moment of access. In the Salesloft Drift campaign, UNC6395 used compromised OAuth tokens against Salesforce instances in August 2025 to harvest credentials such as AWS access keys, passwords, and Snowflake tokens.

A replayed token skips the login entirely, so MFA never activates; authentication already happened when the token was issued. Detection has to look at how the token is used: source addresses, user agents, access patterns, and data exports.

Stolen passwords on accounts without MFA create a related problem. In the 2024 Snowflake campaign, at least 79.7% of the accounts the attacker used had prior credential exposure, and the affected accounts lacked MFA.

The 2023 Okta support-system breach shows what happens when detection works and cross-domain investigation stalls. Within 30 minutes of an admin uploading a HAR file to Okta support, someone tried to access BeyondTrust's Okta admin console from an anonymizing proxy, and BeyondTrust's identity tooling flagged the intrusion. BeyondTrust asked Okta to escalate the next day, but Okta confirmed the breach only after more than two weeks and later said it missed the suspicious downloads in its logs for 14 days while investigating.

Why Detection Output Is Not the Outcome

A detection produces a lead, and investigation is what turns it into a verdict. Triage routes alerts using metadata, severity, and quick lookups, so it can decide what gets investigated but rarely carries enough context to establish whether an alert is an attack.

Alert volume makes that harder. Vectra's 2026 vendor survey put the average at 2,992 alerts a day, with 63% left unaddressed. The median handoff from initial access to a secondary threat group fell to 22 seconds in 2025, according to Mandiant's M-Trends 2026, which recommends treating routine malware alerts as high-priority indicators of an impending secondary intrusion.

Reaching a verdict draws on telemetry, organizational, and historic context. Telemetry context is the alerts and logs. Organizational context covers policies, approved exceptions, and change windows that teams often keep scattered across documentation and Slack. Historic context records what past investigations concluded and why.

For a suspicious PowerShell event, that means checking the workstation's privilege and purpose, such as admin use versus a training lab, and any approved change window. Latio's James Berthoty, drawing on his time at an MDR provider, calls mapping organizational context one of the largest challenges in security operations and says it needs constant updates as environments change.

Coverage maps rarely show which methods a team runs well. Vendors apply ATT&CK technique labels inconsistently across products, and a heatmap can change substantially just by adding one data source, such as Sysmon process creation. A covered cell tells you a rule exists, without showing that it fires or that anyone investigates its output.

In the SANS 2026 SOC Survey, incidents handled was again the top SOC metric, cited by 70% of respondents and the leader for 10 consecutive years. It measures activity volume, which says little about whether the right threats were caught, or caught early. Better SOC metrics connect investigation outcomes back to detection engineering. Panther says it traces each triage outcome to the rule that fired and, when an alert resolves as a false positive and the logic can be refined, proposes a fix as a pull request.

How to Build a Threat Detection and Response Program

If your detection leans on IOC feeds, audit expiration defaults on every feed and move engineering time toward behavioral analytics higher on the Pyramid of Pain.

If your cloud findings come only from GuardDuty, Defender for Cloud, or Security Command Center, retain raw control-plane logs independently and turn on GCP Data Access logs for the services that matter.

If identity-rooted incidents dominate your incident history, connect HR records, travel data, and device inventory to identity investigations before buying more identity detections.

If an ATT&CK heatmap is your main detection metric, supplement it with per-rule precision, the share of investigated alerts confirmed malicious, and structured investigation dispositions that feed tuning.

If your team cannot investigate every alert today, decide who owns the verdict.

Who Owns the Verdict in Threat Detection and Response

Some teams and providers now use agentic investigation to cover more alerts by automating evidence collection and context assembly across sources. How far that goes toward investigating every alert depends on telemetry access, validation, and human oversight, and people still build and maintain the organizational and historic knowledge those investigations draw on.

Teams that run tools in-house, including AI SOC platforms that automate triage and investigation, keep ownership of verdicts and response actions. Other teams hire a managed service like an MDR provider that investigates agreed-upon alerts and responds within the scope of its contract. Capabilities vary widely between providers, especially in cloud and identity coverage.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. Its AI-native MDR pulls telemetry, organizational, and historic context into each investigation, and its security experts review complex or ambiguous cases.

Frequently Asked Questions About Threat Detection and Response

Is TDR the Same as Incident Response?

The two overlap at the response stage. TDR runs continuously, turning alerts into verdicts, while incident response takes over once an investigation confirms an incident and carries it through containment, eradication, and recovery. NIST's 2025 incident response guidance, SP 800-61 Rev. 3, folds incident response into the CSF 2.0 risk management activities that also cover detection, so the handoff between the two belongs in the same plan.

How Do I Evaluate Behavioral and ML-Based Detection?

Ask which behaviors the system detects, which events and entities it correlates, how its baselines or models are built, and how analysts can inspect the evidence behind an alert. Stateful correlation can be purely rule-based, and an ML anomaly score still uses a threshold to raise an alert. Sommer and Paxson's 2010 paper on machine learning for intrusion detection remains a useful early reference on evaluation: ML is better at finding similarities than outliers, and classification errors in intrusion detection are costly.

Why Does Cloud Detection Over-Fire So Much?

Legitimate DevOps automation, backups, deployments, and admin API calls can resemble attacker activity at the API layer, and Orca lists them as common false-positive sources. Skills compound it. SANS found limited cloud expertise and multicloud complexity outpacing defender capacity in 2025, which makes it harder to tell legitimate automation from abuse in cloud API logs.

Is Threat Hunting Part of Threat Detection and Response?

Threat hunting is the deliberate search for what detection rules miss, and it is usually a separate service from MDR. Many MDR providers run IOC sweeps when a known threat is active, but hypothesis-based hunting is out of scope in most cases and needs a dedicated hunting service or an internal team. In the SANS 2026 Threat Hunting Survey, 32% of respondents named cloud infrastructure the hardest environment to hunt in.

How Long Should Logs Be Retained for Investigation?

Default retention windows can be too short to reconstruct long-running intrusions. M-Trends 2026 reports a global median dwell time of 14 days. Cyber espionage and North Korean IT worker incidents each had a median of 122 days, and BRICKSTORM intrusions lasted nearly 400 days. The report warns that standard 90-day retention can leave teams blind to the initial access vector and full scope. Azure, for example, keeps Activity Log events for 90 days unless you export them with a diagnostic setting.