A SIEM correlation rule is the logic that turns scattered raw events into a single meaningful alert. A SIEM collects logs and events from many sources, and most of those events mean little on their own, but a correlation rule watches for a specific combination of them, occurring together or in sequence, that adds up to something worth an operator's attention. In OT this is how three individually unremarkable events, a failed login here, a firmware upload there, an off-hours setpoint change somewhere else, get stitched into one high-confidence incident that no single source would have raised. This page explains how a correlation rule works, what makes a good OT use case, and why correlation is what makes a SIEM more than a log pile.
SIEM Correlation Rule in one line: A SIEM correlation rule is logic that combines multiple events, often from different sources, into a single alert when they match a defined pattern. Instead of alerting on one event at a time, the rule watches for a meaningful combination, such as a failed login followed by a firmware upload and an off-hours setpoint change, and fires only when the pieces occur together within a time window. In OT this turns individually weak signals from separate systems into one high-confidence incident that no single source could have identified on its own.
A SIEM ingests a flood of events: authentication logs from servers, connection records from firewalls, alerts from intrusion-detection sensors, activity logs from engineering workstations, and change records from control devices. The overwhelming majority of these events are perfectly normal, and even the mildly unusual ones are usually benign in isolation. A single failed login is routine, a firmware update is a legitimate maintenance task, and a setpoint change is what operators do all day. Alerting on each of these individually would bury a team in noise while telling them almost nothing.
A correlation rule extracts meaning by looking at combinations rather than individual events. It defines a pattern: which events, from which sources, in what order or within what time window, and with what shared attributes such as the same user, host, or asset. When the incoming stream matches that pattern, the rule fires a single alert that represents the whole combination, carrying far more weight than any of its parts. The rule is essentially a hypothesis about what an attack or a serious problem looks like when seen across several systems at once.
The power of this is that the combination can be diagnostic even when no individual piece is. A failed login is nothing; a firmware upload is nothing; an off-hours setpoint change is nothing. But a failed login on an engineering workstation, followed minutes later by a firmware upload to a PLC, followed by a setpoint change outside working hours, all tied to the same host, is a coherent story of unauthorized access leading to control-system tampering. The correlation rule is what recognizes that story in the noise and raises it as one alert instead of three shrugs.
A correlation rule has a few standard ingredients. First, the conditions: the specific events it looks for, each described by its source and its distinguishing fields, such as an authentication failure from a workstation log or a firmware-upload event from a controller. Second, the join, which is what ties the events together, most often a shared entity like the same user account, source host, or target asset, so the rule only fires when the events genuinely relate to one another rather than coinciding by chance across unrelated systems.
Third, the time window, which bounds how close in time the events must occur to count as related. Requiring the sequence within, say, a short span keeps the rule focused on a real, connected episode and prevents it from linking a failed login today with an unrelated setpoint change next week. Fourth, sometimes a threshold or a sequence requirement, so the rule can demand a certain number of occurrences or a specific order, distinguishing one stray failed login from a burst of them or requiring that the login precede the control action rather than follow it.
Writing good OT rules leans on what makes control networks distinctive. Because OT is deterministic, off-hours activity, engineering-class actions, and control changes are genuinely rare and therefore strong signals, so rules built around them fire seldom and mean a lot when they do. Context specific to OT, such as knowing that a particular asset should never receive a firmware upload during production or that a setpoint change on a critical loop outside a maintenance window is abnormal, lets a rule encode real operational knowledge. The best rules translate an engineer's sense of what should never happen into logic the SIEM can watch for continuously.
OT correlation is most valuable when it spans both control and security data, because the strongest stories cross that boundary. A setpoint change is a SCADA-side event, a failed login is an IT or authentication event, and a firmware upload might come from a control-device log or an IDS detection. A correlation rule that can draw on all of these sees connections that a purely security-focused or purely operational view would miss, tying an authentication anomaly to an actual change in the physical process, which is precisely where security and safety meet in an industrial plant.
This is also where a SIEM complements the more specialized OT monitoring tools rather than replacing them. Intrusion detection, passive network monitoring, and DPI each produce their own events, and the SIEM's job is to be the place where those OT-specific detections meet IT logs and get correlated into complete incidents. A behavioral anomaly from an OT sensor gains enormous weight when a correlation rule links it to a failed login and an off-hours change, and that stitched-together picture is far more actionable than any one tool's alert considered alone.
For distributed operations, correlation has to work across sites as well as across sources, and this is where a centralized platform earns its place. A cloud SCADA or security platform such as Merobix that gathers events from many plants and remote assets can run correlation rules over the whole fleet, so a pattern that would be invisible within one site, such as the same suspicious sequence recurring across several sites, becomes a single fleet-wide alert. Correlation is ultimately what converts a mountain of raw events from many systems and many places into the small number of high-confidence incidents a team can actually act on.
Because individually most events are benign and alerting on each buries the team in noise while revealing little. A single failed login, a routine firmware update, and an ordinary setpoint change are each normal on their own, so alerting on each one either floods the team or gets ignored. A correlation rule instead fires only when a meaningful combination occurs together, so it stays quiet during normal operation and raises a single high-confidence alert when the pieces add up to a real incident.
Usually a shared entity and a time window. The rule joins events by something they have in common, such as the same user account, source host, or target asset, so it only links events that genuinely relate rather than ones that coincidentally happen across unrelated systems. It also bounds them within a time window so the events must occur close enough together to be part of one connected episode, and it may require a specific order or a minimum count to match a real attack pattern.
Building it around the things that are genuinely rare on a deterministic control network, because those are the strongest signals. Off-hours activity, engineering-class actions, firmware uploads, and control changes on critical loops are uncommon in normal OT operation, so rules built around them fire seldom and mean a lot when they do. The best OT rules encode real operational knowledge, such as a particular asset never receiving a firmware upload during production, turning an engineer's sense of what should never happen into logic the SIEM watches for continuously.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.