Security analytics, explained

A large organization's IT environment generates more log data in a day than any human could read in a lifetime — authentication events, network flows, endpoint activity, cloud API calls. Security analytics exists because a real attack is hidden somewhere inside that volume, usually as a sequence of individually unremarkable events that only look suspicious in combination. The field's central challenge isn't collecting the data; it's separating the small number of events that matter from an overwhelming amount of noise, fast enough to act before damage is done.

The questions people ask

A security operations team asks whether an alert firing right now represents a real attack or a false positive. An incident responder asks how an attacker got in, what they touched, and whether they're still present. A CISO asks how long it typically takes the team to notice and contain a threat, and whether that time is improving. An analyst evaluating a suspicious file or IP asks whether it's already known to be malicious. Each of these questions pulls from a different layer of the security analytics stack, and knowing which layer you're in matters for choosing the right tool.

The data it runs on

Security analytics runs on an enormous variety of log sources: authentication and identity events, network traffic and firewall logs, endpoint activity, cloud service API calls, DNS queries, and application logs. What all of it shares is volume and heterogeneity — different systems log in different formats, at different volumes, with different retention needs — which is why log aggregation, collecting and normalizing logs from many disparate sources into one searchable system, is the unglamorous foundation everything else in this field is built on.

Core methods and how to read them

SIEM (security information and event management) is the category's central concept: a platform that ingests logs from across an environment, correlates events against detection rules, and surfaces alerts for a human analyst to triage. Modern SIEMs increasingly bundle SOAR (security orchestration, automation and response) capabilities to automate part of the response, not just the detection. The defining operational tension in this category is cost versus coverage: ingesting more log sources improves detection but drives up storage and licensing cost, especially for platforms billed per gigabyte ingested per day.

User and entity behavior analytics (UEBA) takes a different detection approach from rule-based correlation: it establishes a statistical baseline of what normal looks like for a given user or system, then flags deviations from that baseline — a login at an unusual hour, an unusual volume of data accessed — as potentially suspicious, catching novel attack patterns that a fixed rule wouldn't be written to detect in advance.

Indicators of compromise are specific, observable artifacts associated with malicious activity — a known-bad IP address, a file hash, a malware signature — that detection systems can match against directly. They're precise and low-noise when they match, but they only catch what's already been seen and catalogued somewhere; a genuinely novel attack won't trip an indicator-of-compromise match on its first appearance.

The MITRE ATT&CK framework is a widely adopted, publicly maintained taxonomy of attacker tactics and techniques — the specific steps an adversary takes at each stage of an intrusion. Security teams use it as a common vocabulary for describing detections and gaps: mapping which techniques a SIEM's rule set actually covers, and, more usefully, which it doesn't, is a standard way to find blind spots in a detection program.

Threat intelligence is external, contextual information about active threats — who's attacking, with what tools, targeting whom — that enriches an internal alert with outside context. It ranges from open, community-shared indicator feeds to deep intelligence gathered from direct engagement inside criminal communities, and its value is specifically in connecting an internal signal ("this IP contacted our server") to an external fact ("this IP is a known scanner, not a targeted attacker") that changes how urgently it should be treated.

A security operations center (SOC) is the team and function, not a single tool — the people who monitor alerts, triage them, and coordinate response, typically organized around tiers of increasing seniority and investigative depth.

Mean time to detect is the average time between a threat first entering an environment and a security team noticing it — one of the primary metrics used to evaluate whether a detection program is actually working, since a SIEM generating thousands of alerts a day is not the same as a SIEM that helps a team notice real threats quickly.

How the work is done in practice

The SIEM layer splits mainly along deployment model and pricing structure. Microsoft Sentinel is a cloud-native SIEM built on Azure's log analytics infrastructure, billed per gigabyte ingested per day with optional commitment discounts, and is a natural fit for organizations already standardized on Microsoft 365 and Entra ID. Securonix takes a similar cloud-native approach but decouples storage from the analytics layer using a Snowflake-based data lake, aimed at organizations that want very long retention without the cost curve of a traditional index-everything SIEM. Wazuh is the notable open-source option: a free, self-hostable platform combining SIEM and XDR capabilities with no per-gigabyte licensing, appealing to teams that want full control of their detection stack, with the trade-off that they also own the operational burden of running it.

The threat intelligence layer is a distinct, complementary market. Shodan and GreyNoise both index internet-wide scanning activity but for different purposes: Shodan is a search engine over internet-connected devices, used both to find your own organization's unexpectedly exposed systems and, by researchers and attackers alike, to find vulnerable ones elsewhere; GreyNoise specifically classifies that same background scanning traffic as benign or malicious, letting a SOC suppress routine noise rather than chase down every scan. VirusTotal answers a narrower, very common question — is this specific file or URL already known to be malicious — by aggregating verdicts from dozens of antivirus engines at once, with the important caveat that anything submitted through its standard scanning becomes visible to the wider security community rather than staying private.

Common mistakes and misreadings

Equating alert volume with detection quality. A SIEM generating a high volume of alerts is not the same as one that reliably surfaces real threats; without a track record measured against something like mean time to detect, alert volume alone is a poor proxy for effectiveness.

Relying only on indicators of compromise for detection. Indicators of compromise only catch previously catalogued threats; a detection program with no behavior-based layer has a structural blind spot against novel attacks.

Submitting sensitive or proprietary files to a public malware-scanning service. A file submitted through a tool like VirusTotal's standard, free scanning path is shared with the broader security community and antivirus vendors — appropriate for a suspicious downloaded file, inappropriate for anything containing sensitive internal data.

Underestimating per-gigabyte SIEM costs at real ingestion volume. A usage-based SIEM's cost can scale dramatically once every log source an organization actually wants is turned on; modeling ingestion volume at realistic scale, not pilot scale, avoids an unpleasant budget surprise.

Treating the MITRE ATT&CK framework as a checklist rather than a gap-finding tool. Mapping detections against the MITRE ATT&CK framework is most useful for finding what isn't covered, not for claiming completeness once a subset of techniques is addressed.

For the full landscape of SIEM and threat-intelligence tools, see every security analytics tool in this category and every threat intelligence tool in this category.