Frequency Table

What a frequency table shows

A frequency table turns raw event counts into a compact view of how often each categorical value appears for a specific entity. In security analytics, that entity might be a host, user, process, service, or destination, and the table helps distinguish routine behaviour from values that are rare, novel, or absent from the entity’s history.

The main value of the structure is that it reduces a large stream of observations into a small set of repeatable counts. That makes it easier to compare current activity with prior behaviour and to ask whether a value has been seen before, how often it normally appears, and whether the current observation sits inside or outside the expected range.

How frequency tables support behavioural detection

Frequency tables are useful wherever detections depend on familiarity rather than fixed rules. A common value for one entity may be unusual for another, so the same token can be low risk in one context and highly suspicious in another. That is why frequency-based baselines are often used to support first-sighting logic, rarity scoring, and entity-specific anomaly detection.

They are especially helpful for categorical features such as command names, destination domains, parent-child process pairs, file paths, API actions, or user agents. Rather than treating each observation as isolated, the table preserves the history needed to answer whether the value is common enough to be routine or rare enough to merit review.

A frequency table is not a verdict by itself. It is an evidence structure that becomes useful when paired with context such as time window, entity type, and the business meaning of the category being counted.

Why rarity and first-sighting matter

In many detection workflows, the most informative signal is not volume alone but novelty relative to the entity. A value that appears once after months of absence may matter more than a value that appears repeatedly across the whole estate. Frequency tables make that distinction visible by separating repeated behaviour from one-off or newly observed values.

That makes them useful for spotting early signs of compromise, unusual automation, or changes in operational patterns. They can also surface silent drift, where an entity slowly accumulates new categories of activity until the original baseline no longer reflects reality.

The design trade-off is that a rare value is not automatically malicious. Legitimate change, deployment events, maintenance activity, and new integrations can all create low-frequency observations, so the surrounding detection logic must decide what rarity means in context.

Where frequency tables fit in analytics pipelines

Frequency tables usually sit near the feature-engineering layer of a detection pipeline. They can be built from telemetry such as logs, network records, endpoint events, or application traces, then reused by rules, scoring models, or investigation workflows that need a compact summary of prior observations.

They also support explainability. When an alert is triggered because a value is new or unusually uncommon, the frequency table provides a simple reason that analysts can review without needing to inspect the entire event history first.

For good results, the counting logic must match the detection question. A table built for one entity scope or one time horizon can be misleading if it is reused for another without adjustment, because frequency is always relative to the population and window being measured.

Related resources from NHI Mgmt Group

• What breaks when identity controls stop at table-level permissions?
• How should security teams prevent rainbow table attacks on password hashes?
• What do security teams get wrong about faster deployment frequency?
• How should security teams govern PostgreSQL table discovery in production environments?