Analytic

An analytic is the logic that turns telemetry into a detection judgement. In practice, it defines how multiple signals are combined, interpreted, and validated against a technique or sub-technique so analysts can confirm whether observed activity matches adversary tradecraft.

Expanded Definition

An analytic is more than a rule or alert condition. It is the decision logic that links telemetry, context, and validation steps so defenders can determine whether activity is benign, suspicious, or consistent with a known adversary technique. In security operations, an analytic may correlate endpoint events, identity signals, network activity, and cloud logs into one detection judgement. That makes it different from raw telemetry, which only records what happened, and from a full detection use case, which often includes response actions, tuning, and workflow. The term is used across SIEM, XDR, and threat hunting, but the underlying idea is consistent: convert noisy signals into a defensible conclusion. Guidance across vendors varies on how much logic an analytic must contain before it becomes a detection rule, so teams should treat the boundary as implementation-specific rather than universal. The NIST Cybersecurity Framework 2.0 is useful here because it frames the governance expectation for detecting and responding to threats, even though it does not standardise the term itself. The most common misapplication is calling any single alert an analytic, which occurs when a lone threshold or event is mistaken for validated detection logic.

Examples and Use Cases

Implementing analytics rigorously often introduces tuning overhead and investigative complexity, requiring organisations to weigh faster detection against higher maintenance and false-positive review costs.

• A SIEM analytic joins impossible travel, new device registration, and MFA fatigue patterns to flag likely account takeover attempts.
• An endpoint analytic matches parent-child process chains and command-line arguments to identify suspicious script execution consistent with a known intrusion technique.
• A cloud analytic correlates privileged API calls, unusual geolocation, and short-lived credential use to detect potential abuse of cloud control planes.
• An identity-centric analytic watches for repeated failed logins followed by successful access from an atypical location, then validates against approved access windows and recent help desk activity.
• A threat-hunting analytic uses MITRE ATT&CK mapping to test whether a sequence of signals fits a specific sub-technique before escalation to incident response.

Analyst teams often document analytics as reusable logic, with thresholds, correlation conditions, and enrichment sources explicitly stated. That practice makes the judgement explainable, testable, and easier to tune when adversaries shift behaviour. It also helps separate detection intent from response automation, which is especially important when analytics feed NIST CSF-aligned monitoring and response workflows.

Why It Matters for Security Teams

Security teams depend on analytics because they sit between telemetry collection and operational action. If the analytic is vague, defenders get alert noise; if it is too narrow, adversaries bypass it with minor tradecraft changes. Strong analytics improve consistency across analysts, help teams measure coverage against tactics and sub-techniques, and support safer automation in SIEM or SOAR pipelines. They also matter for identity security, because many of the most useful analytics combine authentication behaviour, privileged session activity, and abnormal access patterns. In environments with NHI or agentic AI, the same logic can help distinguish normal service-to-service activity from compromised secrets, misused tokens, or an AI agent acting outside expected tool scope. The operational value is not just better detection, but better explanation of why a judgement was made and what evidence supported it. Teams that do not define analytics clearly often discover the gap only after a missed intrusion, at which point rebuilding detection logic becomes operationally unavoidable.