Key Takeaways
- Signatures catch known-bad; anomaly detection catches unknown-bad by flagging deviations from established normal behaviour.
- Baselining is the foundation: characterise normal volume, timing, sources and sequences before you can detect what is abnormal.
- Frequency rules in Wazuh count events over time windows to catch brute force, beaconing, scanning and data-access spikes that single events never reveal.
- Statistical anomalies: deviation from rolling averages, rare-event detection and first-occurrence alerting surface novel activity.
- The trade-off is noise: anomaly detection needs disciplined tuning and good baselines, or it buries analysts. Scope it to high-value behaviours.
Why Anomaly Detection Complements Signatures
Signature-based detection asks a simple question: does this event match a known pattern of badness? It is fast, precise and low-noise for threats you already understand, which is why a Wazuh deployment starts with 5000+ signature rules. But signatures are blind to anything novel: a new malware variant, a custom attack tool, an insider abusing legitimate access, or a living-off-the-land technique that uses only built-in system tools. None of these match a signature.
Anomaly detection asks a different question: is this event normal for this environment? It does not need to know the specific threat in advance; it flags behaviour that deviates from an established baseline. This catches the unknown-unknowns that signatures miss. The cost is precision: anomalies are not inherently malicious, so anomaly detection produces more events that require human judgement.
The two approaches are complementary, not competing. A mature Wazuh SOC runs signatures as the high-confidence first line and layers anomaly detection on top for the high-value behaviours where novel attacks are most damaging. The art is knowing where to apply anomaly detection so its noise is worth the coverage it adds.
Baselining: The Foundation
Every anomaly is a deviation from a baseline, so the quality of your baseline determines the quality of your detection. Baselining means characterising, over a representative observation period, what normal looks like along several dimensions: volume (how many logins, file accesses, connections per user or host per hour), timing (when activity normally happens), sources and destinations (which hosts, IPs and geographies are normal), and sequences (what order of events is expected).
In Wazuh, baselines are captured several ways. CDB lists encode known-good values such as approved administrative accounts, expected service hosts and normal source networks. Stateful rules with frequency and timeframe attributes encode normal rates so you can alert above them. And the indexer's historical data lets you compute reference averages for a metric, which a rule or scheduled query then compares current activity against.
A critical baselining decision is the unit of analysis. Baselining per individual user is precise but fragile and high-maintenance. Baselining per role (all finance users, all database admins) is more robust and usually sufficient. Most effective Wazuh anomaly programmes baseline by role for behaviour and reserve per-entity baselines for a small set of the most sensitive accounts and systems.
Need a Managed SOC Built on Wazuh?
Codesecure runs Managed SOC on the Wazuh + TheHive + n8n + Cortex + MISP open source stack. 24x7 named analysts, fixed monthly retainer, no per-GB licensing. ISO/IEC 27001:2022 certified delivery across India, Singapore, UAE and Malaysia.
See SOC Services →Frequency and Stateful Rules
The most practical anomaly mechanism in Wazuh is the frequency rule: a stateful rule that fires only when a matching event occurs more than a set number of times within a time window, controlled by the frequency and timeframe attributes. This single mechanism covers a surprising range of detections that no individual event could reveal.
Concrete examples: brute force is N failed logins from one source in M minutes; password spraying is failed logins against many accounts from one source; network scanning is connection attempts to many ports or hosts in a short window; beaconing is regular outbound connections to one destination at a fixed interval; and data exfiltration is file-access or download counts spiking above the role baseline. Each is implemented as a frequency rule with thresholds tuned to your environment.
Stateful rules also support correlation across event types using the if_sid and if_matched_sid relationships, so you can build sequences: a failed-login burst followed by a success (brute-force that worked), or a privilege escalation followed by access to a sensitive system. These multi-step rules are where Wazuh moves from counting to genuine behavioural reasoning about attack chains.
Statistical and Rare-Event Detection
Beyond fixed thresholds, behavioural detection benefits from relative and rare-event approaches. Deviation from a rolling average is more robust than a static threshold because it adapts to your environment: instead of alerting at exactly 100 file accesses, you alert when a user's access count is several times their own recent average. This is implemented with scheduled queries against the indexer that compute the reference average and compare current activity, generating an alert event when the deviation is significant.
First-occurrence and rare-event detection flags things that have never or almost never happened: a user logging into a server they have never touched, a process never seen before on a host, a connection to a country that appears in no historical data. Because these are computed against history, they surface novelty directly. CDB lists of previously-seen values, updated over time, are a simple and effective way to implement first-seen detection.
It is worth being realistic about scope. Wazuh's core engine is rule and threshold based rather than a machine-learning anomaly engine, so the most advanced statistical modelling is implemented through scheduled analytics and integrations rather than native ML. For the large majority of practical SOC anomaly use cases, frequency rules, rolling-average deviation and rare-event detection deliver strong results without the complexity and false-positive challenges of unsupervised ML.
High-Value Anomaly Use Cases
Focus anomaly detection where novel behaviour is both likely and damaging. These use cases consistently justify the tuning effort they require.
- Authentication anomalies: brute force, password spraying, impossible travel, first login to a sensitive system, spikes in failed logins.
- Data access anomalies: access volume far above role baseline, first access to sensitive data stores, mass file reads or deletions.
- Network anomalies: beaconing to a single destination, scanning behaviour, outbound volume spikes, connections to never-seen geographies.
- Process anomalies: a binary never before seen on a host, an unusual parent-child process relationship, a service account spawning a shell.
- Privilege anomalies: first-ever sudo or admin use by a user, new privileged account, escalation outside change windows.
- Cloud anomalies: API call rates above baseline, first use of a sensitive API by a principal, resource creation in unusual regions.
Want Your Wazuh Deployment Tuned Properly?
Whether you run Wazuh in-house or want it operated for you, our SOC engineers handle rule tuning, detection engineering, threat hunting and response playbooks. Book a 30-minute scoping call with a named SOC lead.
Talk to a SOC Lead →Tuning and Operating Anomaly Detection
Anomaly detection lives or dies by tuning. Deployed raw, it generates far more events than signature detection because so much legitimate activity is technically unusual. The first weeks are spent separating benign anomalies (the analyst who works late, the quarterly batch job, the new hire exploring systems) from meaningful ones. This is done by refining baselines, raising thresholds where legitimate variance is high, and adding suppression for known-good patterns.
A useful operating model is tiered confidence: anomaly detections feed a lower-priority queue or a risk-scoring view rather than paging an analyst immediately, while combinations of anomalies (an after-hours login plus a data-access spike plus a first-seen process) escalate to high priority. This risk-aggregation approach, where individual weak signals combine into a strong one, is how anomaly detection delivers value without overwhelming the team.
Codesecure builds anomaly detection as a layer on top of a tuned signature baseline, scopes it to the high-value behaviours that matter for each client, and aggregates weak signals into actionable risk scores through correlation rules and SOAR logic in n8n. We deliver it within a managed SOC or as a detection-engineering engagement with documentation and handover, so your team can maintain and extend it. ISO/IEC 27001:2022 certified delivery.
Frequently Asked Questions
Does Wazuh use machine learning for anomaly detection?
Wazuh's core engine is rule and threshold based rather than a native unsupervised machine-learning anomaly engine. Behavioural anomaly detection is built from frequency and stateful rules, rolling-average deviation through scheduled analytics, and rare-event detection against historical data. For most practical SOC use cases these deliver strong results without the false-positive challenges of unsupervised ML; heavier statistical modelling can be added through integrations.
What is a frequency rule in Wazuh?
A frequency rule is a stateful rule that fires only when a matching event occurs more than a set number of times within a defined time window, using the frequency and timeframe attributes. It is the core mechanism for detecting brute force, password spraying, scanning, beaconing and data-access spikes, none of which any single event would reveal.
How long does baselining take before anomaly detection is useful?
Plan for a representative observation period of two to four weeks to capture normal weekly and monthly cycles, followed by ongoing refinement. The first weeks after enabling anomaly detection involve heavy tuning to separate benign anomalies from meaningful ones. After that initial period the surviving detections become trustworthy.
Will anomaly detection flood my analysts with false positives?
It will if deployed without tuning, because much legitimate activity is technically unusual. The solution is good baselines, role-based thresholds, suppression of known-good patterns, and a tiered model where individual anomalies feed a risk score and only combinations escalate to high priority. Scoping anomaly detection to high-value behaviours rather than everything keeps the noise manageable.
How is anomaly detection different from signature detection?
Signature detection matches events against known patterns of badness; it is precise and low-noise but blind to novel threats. Anomaly detection flags deviations from normal behaviour; it catches unknown threats but produces more events needing human judgement. They are complementary, with signatures as the high-confidence first line and anomalies layered on for novel-attack coverage.
Can Codesecure build anomaly detection on our Wazuh deployment?
Yes. Codesecure builds behavioural baselines, frequency and statistical detection rules, and risk-scoring correlation on top of your signature baseline, scoped to your high-value behaviours. We deliver it within a managed SOC or as a detection-engineering project with documentation and handover. ISO/IEC 27001:2022 certified delivery with named consultants.
Add Behavioural Analytics to Your Wazuh SOC
Codesecure builds baselining, frequency rules and statistical anomaly detection on Wazuh, scoped to your high-value behaviours and aggregated into actionable risk scores. Managed SOC or detection engineering with handover. ISO/IEC 27001:2022 certified delivery.
