Key Takeaways
- Correlation turns isolated events into attack-chain alerts. Wazuh does this with composite rules that only fire when several conditions occur together within a time window.
- Frequency-based rules use the frequency and timeframe attributes to detect bursts, like brute force, port scans or repeated policy violations.
- The if_matched_sid and if_matched_group fields let a rule require that a previous related event already matched, which is how multi-step sequences are detected.
- Cross-source correlation works because Wazuh normalises events from firewalls, endpoints, cloud and applications into a common structure before rules evaluate them.
- Correlation reduces alert fatigue by collapsing many low-value events into a single high-value detection that describes the behaviour, not the symptom.
Why Correlation Matters More Than Raw Alerts
Most security-relevant activity is invisible in any single event. A failed login is routine. A firewall deny is routine. A new scheduled task is routine. The signal lives in the combination: failed logins followed by a success from the same source, followed by a new privileged account, followed by outbound traffic to an unfamiliar host. Correlation is the discipline of detecting that combination rather than its individual parts.
Without correlation a SOC drowns. Every endpoint produces thousands of benign events per day, and an analyst cannot triage them individually. Correlation collapses that volume into a small number of behaviour-level alerts that each describe something an analyst genuinely needs to look at. This is the difference between a SIEM that generates fatigue and one that generates investigations.
Wazuh performs correlation inside the same analysisd engine that handles real-time detection. Because the engine maintains state about recent events, a rule can reference what has already happened, which is the foundation of every multi-step and frequency-based detection.
Frequency-Based Detection
The simplest form of correlation is counting. A frequency rule fires only when a condition occurs a defined number of times within a defined window. In Wazuh this is expressed with the frequency and timeframe attributes on a rule: for example, ten matching events within 120 seconds. This is exactly how brute-force detection works, where a single failed login is ignored but a burst of them is an alert.
Frequency rules apply far beyond authentication. Repeated firewall denials from one source suggest scanning. Repeated web errors of the same type suggest fuzzing or an application attack. Repeated file integrity changes in a short window suggest ransomware or mass tampering. The same counting primitive detects all of these because Wazuh tracks how often a child condition has matched.
Tuning frequency rules is about choosing thresholds that separate normal bursts from attacks. Set the count too low and legitimate activity (a user mistyping a password three times) generates noise. Set it too high and a slow, patient attacker stays below the line. Effective thresholds come from baselining the environment, not from copying defaults.
Need a Wazuh-Based Managed SOC?
Codesecure deploys and operates Wazuh, TheHive, n8n, Cortex and MISP as a managed SOC. 24x7 named analysts, detection engineering, tuned dashboards and audit-ready compliance reporting. No commercial SIEM licensing.
See Managed SOC →Composite and Sequential Rules
Counting answers how many. Sequence answers in what order. Wazuh expresses sequence through the if_matched_sid and if_matched_group attributes, which make a rule conditional on a previous matching event. A rule can say, in effect: fire only if this event occurs and an event matching rule 5710 (failed SSH) already matched recently from the same source.
This is how attack chains become single alerts. Consider account compromise: multiple failed logins (one rule), then a successful login from the same source (a second rule that uses if_matched_sid to require the failures came first), then privilege escalation (a third rule chained to the success). The final alert carries the whole story rather than three disconnected events.
The same_source, same_user and same_id qualifiers tighten these chains so that correlation only links events that genuinely belong together. Without same_source, a rule might wrongly correlate failed logins on one host with a success on a completely unrelated host. Precise qualifiers are what keep composite detections accurate rather than coincidental.
Cross-Source Correlation
Real attacks cross system boundaries. An intrusion might show as a firewall event, then an endpoint process event, then a cloud API call, then a database query. Correlating across these requires that events from very different sources are normalised into a comparable structure. Wazuh decoders do exactly this, extracting source IP, username, action and outcome from heterogeneous log formats into common fields.
Once normalised, a rule can correlate a firewall allow with a subsequent suspicious process on the same destination host, or a cloud console login from a new country with a sensitive configuration change moments later. The decoder layer is therefore the unsung enabler of cross-source analytics: correlation is only as good as the field extraction underneath it.
For estates that span on-premise infrastructure and multiple cloud providers across India, Singapore, the UAE and Malaysia, cross-source correlation is what unifies the picture. Instead of separate consoles for each platform, the SOC sees one correlated narrative because every source feeds the same rule engine through consistent decoders.
Adding Context with MITRE ATT&CK Mapping
Correlation tells you that several things happened together. MITRE ATT&CK mapping tells you what that combination means. Wazuh rules can be tagged with ATT&CK technique IDs, so a correlated alert is automatically associated with tactics like Credential Access, Privilege Escalation or Lateral Movement.
This context transforms triage. An analyst seeing a correlated alert tagged with consecutive ATT&CK techniques can recognise an in-progress kill chain and prioritise accordingly, rather than treating it as an isolated curiosity. Dashboards can then aggregate detections by tactic, showing the SOC which stages of the attack lifecycle are most active in the environment.
Want Help With Detection Engineering?
Whether you run Wazuh in-house or want a fully managed service, our SOC engineers build custom rules, dashboards and integrations tuned to your environment. ISO/IEC 27001:2022 certified delivery, fixed-fee monthly retainer.
Talk to a SOC Engineer →Building and Tuning Correlation Rules
Good correlation is engineered, not enabled. Start from the behaviours you care about (account takeover, lateral movement, data staging) and work backwards to the sequence of observable events each one produces. Each step in the sequence becomes a base rule, and the chain is assembled with if_matched logic and same_source style qualifiers.
Test correlation rules against real attack telemetry, not just synthetic events. A rule that fires cleanly in a lab can be too tight or too loose against production noise. The iterative loop is: write the chain, replay representative activity, measure false positives and missed detections, then adjust thresholds and qualifiers. This is the core of detection engineering.
Correlation also needs maintenance. As the environment changes (new applications, new cloud services, new normal behaviour) the baselines that made a threshold sensible can drift. Codesecure treats correlation rules as living detections, reviewing thresholds, ATT&CK coverage and false-positive rates as part of ongoing SOC operations rather than a one-time setup.
Frequently Asked Questions
What is correlation in Wazuh?
Correlation is detecting meaningful combinations of events rather than individual events. Wazuh correlates using frequency rules (counting events within a window) and composite rules (requiring that related events occurred in sequence), so scattered low-value events collapse into a single behaviour-level alert.
How does Wazuh detect brute-force attacks?
With frequency-based rules. A rule uses the frequency and timeframe attributes to fire only when a number of failed authentications occur within a window, for example ten failures in 120 seconds. A single failed login is ignored; a burst is flagged. The same_source qualifier ensures the failures come from one origin.
What are if_matched_sid and if_matched_group?
They are rule attributes that make a rule conditional on a previous matching event. if_matched_sid requires that a specific earlier rule already matched; if_matched_group requires that any rule in a group matched. Combined with same_source or same_user, they let Wazuh detect multi-step sequences like failed logins followed by a success followed by privilege escalation.
Can Wazuh correlate events from different sources?
Yes. Wazuh decoders normalise events from firewalls, endpoints, cloud platforms and applications into common fields such as source IP, user and action. Once normalised, rules can correlate across sources, for example linking a cloud console login from a new location to a sensitive configuration change that follows it.
Does correlation reduce false positives?
It reduces alert fatigue by collapsing many low-value events into one high-value detection that describes the behaviour. Correlation must still be tuned: thresholds and qualifiers that are too loose create coincidental matches, while too-tight rules miss slow attackers. Effective thresholds come from baselining the specific environment.
Does Wazuh support MITRE ATT&CK mapping?
Yes. Rules can be tagged with ATT&CK technique IDs, so correlated alerts are automatically associated with tactics like Credential Access and Lateral Movement. This lets analysts recognise an in-progress kill chain and lets dashboards aggregate detections by attack lifecycle stage.
Turn Scattered Events Into Attack-Chain Detections
Codesecure builds and tunes Wazuh correlation rules mapped to MITRE ATT&CK, so your SOC sees behaviours instead of noise. ISO/IEC 27001:2022 certified delivery, named OSCP and CEH detection engineers, fixed monthly retainer.
