A useful FortiSIEM incident rule is not simply a condition that can fire. It is a detection that turns a meaningful pattern of events into an incident an analyst can understand, prioritize, investigate, and eventually clear. Poor rules do the opposite: they trigger on harmless repetition, group unrelated activity together, omit the context an analyst needs, and create so much alert volume that important behavior disappears inside the noise.

The current NSE 7 Security Operations 7.6 Architect scope explicitly includes configuring FortiSIEM incident rules and analyzing the incidents those rules generate. That makes rule design a detection-engineering problem, not a checkbox exercise. The strongest approach begins with the behavior you want to detect, identifies the event evidence that represents that behavior, and then builds filters, grouping, aggregation, timing, exceptions, and incident attributes around that hypothesis.

Start with the behavior, not the available event fields

A rule should answer a security question. “Did one account fail authentication repeatedly from the same source?” is a question. “Event type equals login failure” is only a filter. The difference matters because raw events are usually too granular to be useful incidents. A busy identity system can produce thousands of isolated failures that are normal; the suspicious pattern is often the concentration, sequence, source, target, or timing of those failures.

Write the detection hypothesis in plain language before touching the rule editor. Define the actor or entity you want to group by, the minimum evidence that should exist, the time window in which the activity becomes meaningful, and the expected benign explanations. This forces the detection to model behavior instead of merely mirroring a log message.

That same discipline underlies a mature SIEM program. Collection is necessary, but detection quality comes from relating normalized events to a threat model and operational response. A rule that no analyst trusts is technically active but operationally close to useless.

Use filters to make the population precise

FortiSIEM rule conditions begin by deciding which events are eligible for evaluation. Filters should be specific enough to represent the behavior without excluding legitimate variants. If a rule is meant to detect repeated administrative authentication failures, for example, the filter may need event type, device class, protocol, account characteristics, or target role. If it is written too broadly, routine user mistakes create noise. If it is written too narrowly, an attacker can change one attribute and fall outside the rule.

Normalization quality is critical here. A rule can only compare attributes that FortiSIEM has actually parsed and populated. When a detection does not fire, verify the underlying events first: confirm that the expected event type is arriving, the relevant attributes are populated, and the values look consistent across the devices in scope. A logic-perfect rule built on an empty or inconsistently parsed field will still fail.

Device groups, network groups, watch lists, CMDB context, and event-type groups can help keep the filter readable. They also reduce maintenance. It is easier to update a named group of critical servers than to edit dozens of rules that hard-code individual addresses.

Group by the entity whose behavior you are measuring

Grouping is one of the most consequential choices in a correlation rule. Suppose ten failed logins occur in five minutes. If the rule groups by nothing, failures from unrelated users and hosts may combine into one threshold. If it groups by source IP only, one compromised workstation trying many accounts becomes visible. If it groups by source and destination, the rule becomes more specific to one path. If it groups by username, distributed attacks against one account may emerge instead.

There is no universally correct group-by set. Choose the attributes that define a single security story. For password spraying, grouping by source and counting distinct users may be useful. For a targeted brute-force attempt, grouping by destination and username may be more meaningful. For scanning, the source is often the stable entity while distinct destinations or ports become the aggregate being counted.

Over-grouping can be as damaging as under-grouping. Adding too many attributes fragments one malicious campaign into tiny groups that never cross the threshold. It can also increase the amount of state the rule engine must maintain. Detection design should preserve the entity relationships necessary to prove the hypothesis and omit fields that do not change the investigative meaning.

Aggregation turns events into behavior

FortiSIEM rules can use aggregate conditions such as counts, distinct counts, averages, and other functions to decide when a pattern becomes incident-worthy. A simple count answers “how many matching events occurred?” A distinct count can answer stronger questions such as “how many different accounts did this host try?” or “how many destinations did this source contact?” Those questions are often closer to adversary behavior than raw event volume.

Thresholds should be defensible. Start from observed baseline data when possible rather than choosing a round number because it looks plausible. A threshold that works for a small branch may be meaningless in a large identity environment. If normal administrators generate bursts during maintenance windows, account for that context rather than raising the threshold so high that malicious activity disappears.

Time is part of the threshold. Twenty failures in thirty seconds is a different signal from twenty failures in a week. The detection window should reflect how quickly the behavior matters, how quickly logs arrive, and how analysts intend to respond. Short windows increase sensitivity to bursts; longer windows can reveal low-and-slow behavior but may require more careful grouping and false-positive control.

Use multiple subpatterns when sequence changes the meaning

Some behaviors cannot be expressed well as one aggregate. FortiSIEM supports relationships between subpatterns, including logical combinations and temporal relationships such as activity followed by another activity. This is valuable when the sequence itself is evidence.

Consider repeated failed logins followed by a successful login from the same source to the same target. The success is not automatically malicious, but the sequence is more informative than either event type alone. Another example is a detected attack against a server followed by that server initiating broad connection attempts. Relating the destination of the first pattern to the source of the second can express a possible compromise-and-spread story.

Multi-pattern detections should remain explainable. If a rule uses many nested relationships that analysts cannot reconstruct from the incident, tuning becomes difficult and false positives linger. Prefer the smallest sequence that materially raises confidence, and expose the correlated attributes in the generated incident so the reasoning is visible.

Exceptions should represent known context, not hide bad tuning

Exceptions are appropriate when a known business condition would otherwise create a predictable false positive. Maintenance windows, vulnerability scanners, authorized penetration tests, backup systems, and other controlled processes can legitimately match threat-like behavior. FortiSIEM allows exceptions to be tied to event attributes and effective time periods, which is more precise than permanently excluding a broad network range.

The danger is using exceptions as a substitute for fixing weak logic. If analysts continually add hosts to an exclusion list because the rule fires on ordinary operations, revisit the filter, grouping, threshold, and window. Every exception expands a blind spot. It should have an owner, rationale, scope, and review date.

False-positive resolution data is also feedback. If the same pattern is repeatedly cleared as benign, treat that as detection-engineering evidence. The goal is not zero false positives at any cost; it is a signal-to-noise ratio that lets analysts respond to material incidents with confidence.

Design the incident for the analyst who receives it

A detection is incomplete until the resulting incident contains enough context to act on. Use a title that identifies the behavior, not merely the rule name. Set severity according to credible impact and confidence rather than making every security incident high severity. Include triggered attributes that help the analyst answer who, what, where, and when without reopening raw searches for basic facts.

Category, subcategory, tactics or techniques, affected assets, source and destination, account identity, counts, and relevant event details should align with the investigation workflow. If a rule groups by source IP but the incident does not expose that source clearly, the analyst loses the very context the rule used to correlate the behavior.

Clear conditions matter too. An incident that stays active forever after the triggering behavior stops becomes stale operational debt. Where the behavior supports it, define a condition that lets FortiSIEM move the incident out of the active state after the original rule no longer triggers or after a related clearing pattern occurs.

Test with real events before activation

FortiSIEM guidance emphasizes testing rules before activating them. Run the intended logic as a query against a representative historical period and inspect the matched population. Look at true positives, obvious benign matches, grouping behavior, and whether the threshold behaves the way the plain-language hypothesis predicted.

Testing should include negative cases. Confirm that approved administrative behavior, scheduled tasks, and known scanners do not accidentally meet the detection. Then test boundary conditions: just below the threshold, exactly at the threshold, and above it. For sequence rules, verify both correct order and incorrect order. This is more informative than simply waiting for production incidents to appear.

When a rule does not trigger despite matching events, troubleshoot systematically. Confirm parsed fields, maintenance state, exception conditions, event timing, and whether the rule is too loosely grouped or producing excessive incident volume. FortiSIEM includes protections against incident floods; a rule that generates an unreasonable number of incidents can create system-level symptoms as well as analyst fatigue.

Tune detections as part of an operating cycle

Production detection engineering is iterative. Review high-volume rules, rules with consistently low true-positive value, incidents that analysts repeatedly reclassify, and rules that have not triggered despite known test cases. Changes to log sources, parser behavior, infrastructure, identity systems, and attacker techniques can all make yesterday’s tuning obsolete.

A useful review record includes the rule hypothesis, affected data sources, last validation date, owner, expected incident volume, known exceptions, and recent tuning decisions. That documentation turns rule maintenance into an engineering process rather than a collection of unexplained edits.

Fortinet certification objectives connect detection engineering to the rest of SOC architecture: the useful skill is understanding how event evidence becomes a correlated incident and how that incident remains actionable under real operational load.