When Graylog correlation events detect incidents across log sources
A single log source rarely shows an attack chain from start to finish. A VPN login may look normal, an IDS alert may look like noise, and a privilege change may look routine on its own. Correlation events are a Graylog Enterprise feature that ties these separate events together so one detection can span several sources. Graylog Open event definitions evaluate searches against one stream of messages, which covers many single-source alerts well. Teams that need to connect events from different sources, or to check that something expected did not happen, need the Enterprise correlation engine.
The engine supports three patterns. Per-field correlation groups events that share a value, such as a user name, so that activity from one account across several sources is evaluated together. Cross-source sequences look for one event shortly after another from the same origin, such as a successful login immediately following an IDS log from the same IP address. Negative event monitoring raises a condition when an expected event does not occur, for example a backup job completion or a heartbeat that stops arriving. Before building any of these, confirm in the correlation events documentation the exact field names, time windows and how each source is identified in your version, since a mismatched field name will silently prevent matches.
The decision is practical. If a detection needs only one source and one search condition, Open event definitions are usually enough and avoid the license cost. If the detection depends on how events from two or more sources relate, or on the absence of an event, plan for the Enterprise license before designing the rule. Ask the vendor or your licensing contact which correlation features are included in the edition you are quoting, and confirm that the sources you need are normalized to shared field names, because correlation quality depends on that consistency more than on rule complexity.
Correlation patterns and when each fits
This table compares the three correlation patterns in the Graylog Enterprise correlation engine: per-field correlation, cross-source sequences and negative event monitoring. Read each column to match the detection question to the data it needs and the tuning trade-off it brings, since all three require an Enterprise license.
| Pattern | Detection question it answers | Data it needs | Main tuning trade-off |
|---|---|---|---|
| Per-field correlation | Is one entity, such as a user name, producing repeated events from several sources within a window? | Events from more than one source that share a common field, normalized to the same field name | Window length and grouping field: a wide window or a broad field such as a shared service account can raise false positives |
| Cross-source sequence | Did an event from one source happen shortly before a related event from another, such as a login after an IDS alert from the same IP? | Two or more event types from different sources linked by a shared key, such as a source IP, with reliable timestamps | Time window between the first and second event: too short misses slow attackers, too long links unrelated activity |
| Negative event monitoring | Did an expected event fail to occur within a set period, such as a scheduled backup job or a heartbeat from a host? | A reliable stream of the expected event and a defined schedule or interval for it | Expected interval and log delivery lag: pipeline delays or collector outages can trigger false alarms that look like missing events |
| Edition required | Which Graylog license unlocks the pattern? | Graylog Enterprise for all three patterns; confirm current licensing with Graylog before you design around it | Plan the license into the quote from the start, since Graylog Open event definitions do not cover these patterns |
How correlation differs from Graylog Open event definitions
Graylog Open alerts come from event definitions that run a search on a schedule or over historical data and raise an event when the search results meet a condition. Correlation works one level up. It links events across log sources and across time, so a rule can ask whether a login followed an IDS log from the same IP, or whether an expected event never arrived. The practical difference is the input: an event definition watches messages, while a correlation rule watches the results of other detections. Do not assume Open event definitions cover multi-source logic just because they can alert on a single search, and do not assume correlation is a drop-in extension of your existing alert set.
Before you design around correlation, confirm three things with Graylog and in your own environment. First, confirm that your license includes the correlation engine. The correlation events documentation marks it as a Graylog Enterprise feature, and the Graylog pricing page lists it among Enterprise capabilities, so check the current edition terms in your contract rather than relying on a general product description. Second, confirm the configuration screens and rule options in the Graylog version you run, since the documentation is versioned and the current docs cover version 7.2. Third, confirm how your existing event definitions and their notifications will be reused, if at all, as inputs to correlation rules and whether they need to be recreated.
Plan the migration as a test, not a conversion. Pick two or three cross-source scenarios that matter to your team, build each one as a correlation rule in a non-production Graylog cluster, and feed it representative log samples from both sources. Record which events fire, which do not, and how notifications route to your on-call tools. Keep the existing Open event definitions running in production until the correlation rules have been reviewed against those results. Any capability gap you find is a finding for the design review, not something to work around silently.
How to set up a correlation event step by step
This sequence takes a multi-source detection idea from licensing and version checks through field normalization, historical testing and notification routing, so each correlation reaches production only after it has been shown to fire and clear as intended.
Confirm Enterprise licensing and target version
Confirm with your Graylog account owner or licensing contact that your deployment holds a Graylog Enterprise license, because the correlation engine is an Enterprise feature and Graylog Open does not include it. Then record the exact Graylog version you will run, and check it against the current documentation, which covers version 7.2, and the compatibility matrix for your MongoDB and Data Node or OpenSearch versions. Done means you have a written note of the license, the version and the compatibility check, and a test environment on the same version as production.
Map source streams and join keys
List each log source the detection needs, such as an IDS feed and an authentication feed, and identify the field that links them, for example a source IP address or a user name. Confirm which streams hold each source and that the join field exists in every one of them under the same name. Done means you have a short table of stream, source, join field and an example message for each source, reviewed by the team that owns the logs. Where a field is missing in one source, record that gap before building anything.
Normalize fields with pipelines
Attach processing pipelines to the source streams so the join field has one consistent name and format across sources, for example an IP address stored in the same field with the same type. Confirm that pipeline rules run before messages reach the correlation step, because a field that is named differently or stored as text will not match. Done means a sample search on each stream returns the join field populated for the messages you expect, and no unrelated sources share the stream by accident.
Build the correlation and test on history
Create the correlation event in the Enterprise correlation engine, choosing either per-field correlation, such as grouping by user name, or cross-source correlation, such as a login shortly after an IDS alert from the same IP. Set the time window and the matching conditions, then run it against a historical period that contains known events, both malicious and benign. Done means you have a list of matches that a reviewer agrees with, and you have noted the false positives and any tuning needed before enabling it on live data.
Tune and document the rule logic
Adjust the window, the field matching and the exclusions based on the historical results, then record the final logic in a change record with the owner, the purpose and the sources it depends on. If you need to detect an expected event that does not occur, such as a missing heartbeat, configure that negative event monitoring separately and test it with a period when the event is known to be absent. Done means the rule logic and its test evidence are stored where the detection team can find them.
Route notifications to responders
Connect the correlation event to the notification channels your responders use, such as email, Slack or PagerDuty, as documented for Graylog alerting. Confirm the message content includes the join value and the source events, so responders can start an investigation without reopening raw searches. Done means a test notification reaches each intended channel and responders confirm it contains the fields they need.
Verify that alerts fire and clear
Replay or generate a controlled sequence of events that should trigger the correlation, then confirm one alert is raised with the expected join value. Next, send events that should not match, such as a login with no prior IDS alert, and confirm no alert appears. Finally, check that the alert clears or resets as your process defines once the window passes or the event is resolved. Done means the test results are recorded, the expected and unexpected cases behaved as designed, and the rule is approved for production.
Monitor the rule after go-live
After enabling the correlation on production data, review the first set of alerts against your test expectations, watch for new false positives from changed log formats, and check that the source streams keep receiving the join field. Schedule a periodic review of the rule with its owner, and repeat the historical test whenever a source, pipeline or Graylog version changes. Done means the rule has a named owner, a review cadence and a recorded result from its first production period.
Security and operational considerations for correlation
Correlation rules turn several log sources into one detection, so the rules, the data they read and the people who tune them all become part of your security boundary. The cards below cover access, data integrity, timing, search load, alert ownership and change control, each of which should be settled before rules go live.
Restrict who can edit rules
Correlation rules decide what gets flagged and what gets missed, so editing them is a privileged change. Limit edit rights in Graylog's role model to a small group of detection engineers, and give read access to analysts who only need to see results. Review who holds the Enterprise administrator role, since it can change rules, notifications and streams together. Confirm in your own environment which built-in roles can open the correlation editor.
Protect the source data
A cross-source rule is only as trustworthy as the events it correlates. If an attacker can alter or suppress an IDS or authentication log before it reaches Graylog, a sequence such as a login after an IDS alert from the same IP never fires. Restrict write access on the collectors and inputs, send logs over encrypted transport, and monitor for sources that go silent. Treat a silent source as a detection gap, not as a quiet network.
Synchronize clocks across sources
Sequence rules depend on event order, so a skewed clock on one firewall or sensor can make a real login appear before the alert that caused it. Run a time synchronization service on every source and on the Graylog nodes, and check the timestamp field each input uses. Test a known sequence across sources during rollout and compare the recorded times before trusting a window length.
Size the load from correlation windows
Correlation runs searches over a time window for each rule, so wide windows and many rules add load to the search backend that also serves analysts. Start with the narrowest window that still captures the sequence, and schedule heavy rules away from peak investigation hours. Ask your Data Node or OpenSearch team to confirm capacity for the rule count you plan, and watch query latency after each change.
Assign alert tuning ownership
Multi-source rules can produce many events from one noisy source, which trains analysts to ignore the queue. Name one owner for each rule who reviews its false positives, adjusts thresholds and retires rules that no longer match the threat. Record the reason for each change in the rule's description so the next reviewer can see why the threshold moved.
Keep rules under version control
Rules created only in the web interface have no history, no review and no easy rollback after a bad edit. Export rule definitions and store them in a Git repository with pull request review, so each change has an author and an approver. Compare the exported definitions with the running configuration after each deployment to catch drift. Confirm with Graylog which export format your edition supports before you build the workflow around it.
Questions teams ask before building correlation events
What does the Graylog Enterprise license cost and what is it licensed on?
Graylog's pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units. The license is charged on processed data, with no per-user or per-device fees, so the figure to plan around is your daily volume rather than headcount. Correlation is one of the Enterprise features, so it is included in that tier. Confirm the current figures and the volume basis with Graylog before you budget, since the pricing page is the source for them. Ask any partner quoting this work to show the license line separately from implementation fees.
Can Graylog Open build cross-source detections with event definitions?
Graylog Open event definitions cover real-time and historical searches, aggregation and notifications, but the correlation engine is an Enterprise feature. For a single-source condition, such as repeated failed logins from one host, event definitions are usually enough. A sequence that links two sources, such as a login that follows an IDS alert from the same IP, or a check for an expected event that never arrives, is what the correlation engine is documented to handle. Some teams approximate these patterns in Open with saved searches and manual review, which works for a pilot but does not give the same automated grouping and monitoring.
How long does a first correlation take to build and test?
No duration is fixed for this work, because it depends on the number of sources, how consistent their field names are, and how many sequences the team needs. A single two-source sequence on clean, well-parsed data is a small task. Time grows with each source that needs parsing fixes, each field that must be mapped to a common name, and each negative-event rule that depends on a schedule you have to agree. Testing takes as long as it takes to collect representative traffic, including the quiet periods that matter for negative monitoring. Ask for a written timeline tied to a defined list of correlations in the scope.
What must our team provide before a correlation build starts?
Three inputs decide most of the early progress:
- Sample logs from each source, covering normal activity and known incidents, with the raw messages as they arrive.
- A field map that names the fields holding user, IP address, host and event type in each source, and where they differ.
- A test window, ideally a period of live traffic, during which the team can compare what the rules fire on against what analysts already know happened.
You should also name the person who can approve alert thresholds and the destination for notifications. Without these, the build tends to stall on questions that only your team can answer.
Can our own team build correlation events, or do we need outside help?
A team with Graylog administration experience and a clear understanding of its log sources can build simple correlations internally, provided it has an Enterprise license and a test environment. Outside help is most useful where several sources need parsing work, where detections must be reviewed for false positives before they page anyone, or where the team lacks time to maintain rules over upgrades. Whichever route you choose, the write-up should record each correlation, its data sources, its expected behavior and the owner who reviews it. DeployOpen plans and implements Graylog work from a written scope, so the decision comes down to fit with your staff and timeline.
What goes wrong most often with multi-source correlations?
The most common problem is inconsistent field naming. A login event might store the source address in one field and an IDS alert in another, so the correlation matches nothing. Clock skew between sources can also break sequence logic when events are timed close together. Negative event monitoring fails quietly when a source stops sending, which is why it should be paired with a check on input health. Finally, rules tuned on a short test window often produce too many alerts once full traffic arrives. Plan a review period after go-live and keep a record of threshold changes.
Does the Enterprise license change what our security team must maintain?
The license does not remove any operational work. Correlation rules still need review when sources change format, when Graylog is upgraded, and when new detection needs appear. Your team owns the decision about which alerts reach responders and how they are triaged. Confirm with Graylog which Enterprise features are covered by your agreement and which version your deployment runs, since upgrade planning affects rule syntax and dependencies.
Scoping a correlation build before the first rule
DeployOpen scopes correlation work in writing before any rule is built, and the scope starts from the detections the organization needs, not from the correlation features Graylog offers. For each detection use case, the scope should name the log sources involved, the join key that ties events together (for example a user name, a source IP or a host identifier), the time window in which the events must occur, and the action the alert should trigger. Each correlation is then marked as in scope or out of scope. Naming the out-of-scope items matters as much as the in-scope ones, because it stops a request such as 'alert on suspicious logins' from quietly expanding into several cross-source sequences that nobody estimated. Ask the partner to show the proposed join keys against sample messages from each source, so that gaps such as a field that is missing on one device type surface before the build.
The written scope also sets the baseline for tuning. Correlation rules that fire too often or never fire usually trace back to a mismatch between the assumed and the actual data, such as timestamps from different sources that are offset, or an IP field that holds a NAT address on one side. If the scope records the expected event pairs, the thresholds the team agreed on and the data each source was expected to supply, later changes can be compared against a documented starting point. Confirm with the platform owner which Graylog edition and license the correlation features require before the scope is signed, since correlation is a Graylog Enterprise feature.
DeployOpen prepares detection designs, configuration and evidence of how the rules were built and tested, but it does not issue audit reports, attestations or certifications. If a detection must support a compliance assessment, ask the assessor in advance which evidence they will accept, and record that requirement in the scope so the build produces it.
How DeployOpen delivers Graylog correlation work
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including Graylog correlation events for multi-source detection. Each engagement starts from a written scope that defines which log sources, correlation rules and notifications are in and out.
How we scope
- Inventory the log sources, fields and identifiers each correlation rule depends on, such as user name or source IP.
- Confirm the Graylog edition and license needed for the correlation engine before design starts.
- Agree in writing which detection use cases, time windows and notification targets the engagement covers.
How we build
- Configure Graylog correlation events in a test environment first, using representative log samples from each source.
- Check that per-field grouping and cross-source sequences fire on the intended events and stay quiet on normal traffic.
- Test negative event monitoring against known gaps in expected logs so missing-event alerts behave as designed.
How we hand over
- Document each correlation rule with its inputs, logic, time window, owner and expected analyst response.
- Deliver a runbook covering tuning steps, false-positive review and how to add a new source to an existing rule.
- Walk your operations and security staff through the rules and the test results before the engagement closes.
How we support
- Fixed-scope engagements end with written deliverables, so changes after handover are scoped separately.
- Ongoing support, rule tuning and upgrade work are available as a retainer agreed in writing.
- Retainer scope can include reviewing rule behavior after Graylog upgrades and after new log sources are onboarded.
