FortiSIEM correlation rules turn streams of normalized security events into incidents by expressing relationships that matter to the SOC. A rule can look for repeated behavior, sequences across subpatterns, thresholds, or conditions that become meaningful only when several events are evaluated together. The technical editor makes those relationships configurable, but useful correlation still depends on understanding the data, the timing, and the action an analyst is expected to take when the rule fires.
For Fortinet Security Operations, correlation design should begin with a detection objective rather than a desire to create more rules. The best rule reduces uncertainty: it groups evidence into an incident that an analyst can understand, provides enough context to verify the behavior, and avoids converting routine environmental noise into a permanent source of false positives.
Correlation starts with normalized event semantics
FortiSIEM receives data from many products, and correlation is reliable only when the fields used by a rule mean what the author thinks they mean. Before writing conditions, verify the event types, source and destination fields, user identity, device identity, severity, and any parsed attributes used for grouping. A rule cannot repair an upstream parser that maps the same field differently across sources.
The logging discipline described in FortiGate logging and troubleshooting applies here at a wider scale. Detection logic is downstream of data quality. If a field is missing, delayed, or overloaded with different meanings, the analyst may interpret a rule miss as absence of activity even though the real problem is normalization.
Subpatterns should represent meaningful pieces of the behavior
FortiSIEM rules can use subpatterns that define event filters and aggregation behavior. A subpattern should correspond to a recognizable part of the security hypothesis, such as failed authentication attempts, a privilege change, a new service, or a network connection to a restricted destination. Separating those pieces makes a rule easier to test and explains which evidence satisfied the condition.
Do not split a rule into many subpatterns simply because the interface allows it. Each additional component creates another timing, grouping, and data-quality dependency. A compact rule that captures the necessary evidence is usually easier to maintain than a sprawling one that attempts to encode an entire incident response playbook inside correlation logic.
Relationship operators define whether events really belong together
Current FortiSIEM documentation supports relationships such as AND, OR, FOLLOWED-BY, AND-NOT, and NOT-FOLLOWED-BY between subpatterns, with additional inter-subpattern constraints available. Those operators are security semantics, not merely query syntax. FOLLOWED-BY expresses order; AND says both conditions matter without necessarily establishing sequence; negative relationships can identify an expected event that never occurred.
Sequence rules are especially sensitive to time windows. If the interval is too short, slow activity disappears. If it is too long, unrelated events can be joined into the same incident. The same reasoning used in alert correlation applies: a relationship should be defensible when an analyst asks why these events were grouped.
Grouping keys determine incident granularity
A threshold on failed logins means very different things when grouped by source address, username, destination system, or a combination of attributes. The key should match the entity whose behavior the rule is meant to characterize. Grouping only by source IP may merge many users behind a proxy; grouping only by username may hide a distributed attack originating from several locations.
Use actual event samples to test grouping behavior before activation. The current NSE 6 FortiSIEM Analyst context is a reminder that correlation is partly operational analytics. A rule author needs to understand not only how to configure a condition, but also how the event model and environment shape the resulting incident.
Streaming and scheduled evaluation solve different problems
FortiSIEM supports streaming, scheduled, and scheduled-via-SQL evaluation modes in current releases. Streaming rules evaluate in real time and are suited to conditions that need immediate detection. Scheduled modes can evaluate larger time windows or use more complex analytics, including SQL-based logic in supported ClickHouse deployments. The choice affects latency, scalability, testing, and what evidence is available in the generated incident.
Scheduled logic should not be selected simply because a query is difficult to express in streaming form. Ask whether the detection can tolerate the delay, whether analysts need the triggering events attached directly, and how the rule will be tested and monitored. Detection architecture should match the response objective, not just the authoring convenience.
Exceptions should be narrow, justified, and time-aware
Every mature rule accumulates benign cases: maintenance systems, known scanners, service accounts, migration activity, or a business process that resembles the threat behavior. FortiSIEM supports rule exceptions, but broad exclusions can quietly remove the very visibility the rule was created to provide. The correct response to noise is to understand it first.
Scope an exception to the smallest stable attributes that explain the benign behavior and use time bounds when the exception is temporary. Record the owner and reason. The signal-quality mindset in SIEM alert triage is relevant before an incident ever reaches the analyst: tuning should remove known benign patterns without erasing new variants.
Testing should validate both logic and incident context
FortiSIEM provides rule testing capabilities for appropriate rule types, including the ability to inject or work with representative events. Current documentation also notes limitations for scheduled modes, which cannot be tested in exactly the same way as streaming rules. That makes pre-production validation and historical search especially important for rules that depend on scheduled evaluation.
A successful test should prove more than “the rule fired.” Check the incident name, severity, grouping, triggering evidence, affected entities, and any remediation or automation actions connected to the rule. A correlation rule that detects the right pattern but creates an unusable incident still imposes work on the SOC.
Rule health and incident quality need continuous review
After activation, measure incident volume, analyst dispositions, repeat offenders, false positives, time-to-triage, and the proportion of incidents that lead to meaningful response. Sudden silence may indicate a successful control, but it can also indicate a parser change, disabled source, field mapping issue, or rule modification. A spike may reflect a new attack or a noisy software deployment.
The SIEM architecture perspective treats rule execution as one layer in a pipeline that can fail. Monitor source health and detection outcomes together. Rules should have named owners and review dates so stale assumptions do not remain active indefinitely.
Severity and incident naming should be designed with the analyst experience in mind. If every rule creates a “critical” incident, severity no longer helps triage. Names should describe the behavior and affected entity, while severity should reflect both the security significance and the confidence of the correlation. The rule is responsible for producing a useful case record, not merely detecting a pattern.
Clear conditions also deserve attention because a correlation can remain active after the original triggering condition has ended. For rules that support clearing, define what evidence means the state is no longer true and whether time alone is sufficient. An incident about a persistent condition should not remain open indefinitely simply because the detection logic has no concept of recovery.
When rules are created from Analytics searches, review the generated defaults instead of assuming the search semantics automatically produce an appropriate incident rule. Group-by fields, thresholds, and the matched-events condition may need to be changed for production. Search is exploratory; a production rule must be stable under continuous event volume and predictable enough for analysts to trust.
Finally, maintain a small test corpus for important correlation rules. Representative raw events, known benign sequences, and expected malicious patterns make future upgrades and parser changes easier to validate. When a collector or parser changes, rerunning those tests can reveal whether the correlation still sees the attributes and relationships on which it depends.
Correlation content should be reviewed after major infrastructure changes. Authentication migrations, proxy redesigns, cloud adoption, new endpoint agents, or identity-provider changes can alter event volume and field semantics without touching the rule itself. A periodic review tied to those changes is more effective than waiting for false positives to become obvious to analysts.
Documentation should include the rule’s purpose, required data sources, key attributes, evaluation mode, time window, exceptions, incident action, and owner. That record becomes the troubleshooting map when a rule stops firing or starts producing unexpected volume. It also lets the SOC retire rules whose original threat model or business dependency no longer exists.
Correlation rules should create investigations, not merely alerts
A strong FortiSIEM correlation rule captures a meaningful behavior, uses trustworthy normalized fields, groups on the right entities, applies a time relationship that matches the threat, and creates an incident with enough evidence for an analyst to act. Streaming and scheduled modes are tools for different detection shapes, while exceptions and tuning keep the rule aligned with real environmental behavior.
Teams using Fortinet should judge correlation rules by the investigations they produce. The objective is fewer disconnected signals and more coherent evidence. When the SOC can explain why the events belong together, test the logic, and measure the outcome, correlation becomes a reliable detection control rather than another source of queue volume.
