FortiSIEM correlation rules convert streams of events into incidents when defined conditions, relationships, and thresholds are met. The platform supports event filters, aggregation, group-by logic, multiple subpatterns, temporal relationships, incident attributes, exceptions, and clear conditions. The difficult work is not learning where those fields are configured. It is modeling behavior precisely enough that a rule detects an operationally meaningful condition without turning normal variation into a permanent alert storm.
FortiSIEM correlation rules turn normalized event streams into incidents by combining filters, subpatterns, aggregation, group-by logic, and incident actions. Those are core skills in the current NSE6-FSM-AN-7-4 scope, where the difficult part is not creating a rule that fires but expressing a security hypothesis precisely enough that analysts can trust the resulting signal.
Start with the event population before adding thresholds
Parser health is therefore a detection dependency. If a vendor update changes an event field or the parser begins classifying events as unknown, the rule may stop matching without any change to its configuration. Monitor the event types and attributes that critical rules consume, and investigate sudden drops in their source populations. A quiet rule is not proof of a quiet environment.
Every correlation rule begins with filters that define which events are eligible. If the population is wrong, later aggregation cannot rescue the detection. Use normalized event type, device role, source, destination, user, application, or other fields to describe the behavior under investigation. Validate the filter with historical search before enabling a rule.
A precise filter also protects performance. Broad rules that ingest huge event populations and discard most of them late in evaluation waste compute and increase tuning complexity. SIEM architecture is more resilient when detection logic narrows data deliberately and when the team knows which parsers and normalized fields each rule depends on.
Aggregation expresses what “enough activity” means
Many useful detections require repeated behavior rather than one event. FortiSIEM can count matching events, count distinct values, calculate averages, and apply other aggregate conditions. A scan might be modeled as one source contacting many distinct destinations; account spraying might be one source failing against several users; infrastructure health might require multiple samples above a threshold.
Choose the aggregation that represents the attacker or operational behavior, not the one that is easiest to configure. COUNT of events can be dominated by duplicate logging, while COUNT DISTINCT of destination IPs may better express breadth. AVG CPU utilization may be useful for performance, while MAX can reveal a spike. Test the statistic on real baseline data before deciding the threshold.
Group-by fields define the entity whose behavior is evaluated
Thresholds should be tuned per entity class when baseline volumes differ significantly. A domain controller, internet proxy, and employee workstation naturally generate different connection patterns. One global threshold can either overwhelm analysts with infrastructure noise or miss quieter attacks on user devices. CMDB groups and other contextual objects can help scope rules to populations whose behavior is comparable.
Group-by is one of the most consequential choices in a rule. If the rule groups login failures only by destination server, failures from many unrelated users may be combined. If it groups by source and destination, it tests a more specific behavior. Adding too many fields fragments one attack into small groups that never cross the threshold.
Write the detection in plain language first: “the same source contacts 100 destinations on the same port” tells you which fields belong in group-by. Then verify that those fields are normalized consistently across the data sources being used. SIEM triage begins before the alert exists, with entity modeling that matches the behavior analysts will investigate.
Subpatterns let a rule express sequence and absence
When a rule uses several subpatterns, name them after the behavior they represent rather than P1, P2, and P3 alone. Descriptive names make later troubleshooting faster and reduce mistakes when inter-pattern constraints are edited. Detection logic is maintained over time by people who may not have authored it, so readability has direct operational value.
FortiSIEM supports multiple subpatterns connected by operators such as AND, OR, FOLLOWED-BY, AND-NOT, and NOT-FOLLOWED-BY in supported rule modes. These relationships let detections describe more than volume. A failed-login pattern followed by a successful login from the same source can mean something different from failures alone; an attack event followed by outbound scanning can indicate a compromised server.
Absence logic is especially powerful and easy to misuse. “Not followed by success” requires enough time to know that success did not occur, so the window influences both detection latency and correctness. Document temporal assumptions and test delayed event ingestion. A sequence rule that assumes perfect event ordering can fail silently when one source arrives late.
Two subpatterns occurring in the same window are not necessarily related. FortiSIEM can constrain fields across subpatterns so the destination in one pattern must equal the source in another, or so the same user, address, or host participates in both. These constraints are the equivalent of proving a join condition rather than correlating by time alone.
Use only fields that retain the same meaning across sources. NAT, proxies, shared accounts, ephemeral addresses, and inconsistent host naming can make equality misleading. When identity is uncertain, combine several attributes or add enrichment rather than forcing a brittle match. Strong correlation is evidence of relationship, not merely coexistence.
Incident attributes should help an analyst act
When a rule triggers, FortiSIEM creates an incident with attributes derived from rule conditions and triggered events. Choose fields that support triage: affected host, source, destination, user, technique, severity, and other identifiers that let analysts pivot quickly. A detection can be technically accurate and still operationally poor if the resulting incident contains no useful context.
Triggered attributes also affect dashboards and analytics. Preserve the fields needed to measure detection performance later. Sequence reconstruction is faster when the incident already exposes the entities and times that caused the rule to fire rather than forcing analysts to reproduce the search from scratch.
Exceptions should represent known context, not hide bad logic
Every exception should have an owner, a reason, and a review condition. Temporary maintenance windows, approved scanners, and known service behavior can justify exclusions, but permanent broad suppressions often become blind spots after infrastructure changes. Treat exception lists as security configuration: review them against current assets and remove entries whose original business justification no longer exists.
FortiSIEM supports rule exceptions with attribute conditions and optional effective time periods. Maintenance windows, approved scanners, backup infrastructure, and controlled test systems can justify exceptions. Exceptions should be specific, time-bounded where practical, and owned by someone who can confirm the business need.
If the exception list grows faster than the rule’s value, redesign the detection. Broad exclusions can create blind spots, especially when they exempt privileged infrastructure attackers are likely to abuse. Tune the base population and thresholds first; use exceptions for legitimate deviations that cannot be modeled safely another way.
An alerting system that never clears incidents forces analysts to maintain state manually. FortiSIEM clear conditions can change an active incident to cleared when the original rule no longer triggers for a defined period or when a separate subpattern indicates recovery. This is especially useful for availability and persistent-condition rules.
Clear logic should match the failure mode. A login attack does not become harmless simply because no new failures occurred for ten minutes; an infrastructure health condition might. For security incidents, containment and analyst disposition may be more meaningful than automatic clearing. Use state transitions that reflect operational truth rather than dashboard cleanliness.
Test with search data before enabling streaming detection
Testing should also verify incident titles, severity, MITRE mappings, notification routing, and triggered attributes. A rule that detects correctly but produces an unhelpful incident can still waste analyst time. Validate the entire operational artifact that reaches the SOC queue, not only whether the condition returned true in a search.
FortiSIEM can create a rule from search results, carrying filter, display/grouping, and initial aggregate logic into a rule template. That workflow is valuable because analysts can inspect historical matches before activation. Modify the generated threshold deliberately; a default count of one is rarely the final production design for a correlation use case.
Replay representative benign and malicious periods, inspect which entities group together, and estimate event volume. When the rule is enabled, monitor first-fire behavior closely. Security-operations architecture should include a safe path from hypothesis to historical query, inactive rule, monitored activation, and tuned production control.
Detection engineering is complete only after feedback reaches the rule
Review rule performance after parser upgrades, collector changes, and major network or identity migrations. Those changes can alter event volume and field meaning without changing the rule itself, so a previously well-tuned threshold may drift into noise or silence even though its configuration appears untouched.
Change control should record why a threshold, exclusion, or subpattern was altered and which historical cases motivated the change. That history prevents teams from reintroducing a previously rejected tuning decision months later and helps new analysts understand why a rule behaves differently from a simple textbook example.
Track incident volume, confirmed malicious rate, recurring false-positive causes, data-source failures, analyst closure reasons, and the effect of exceptions. A rule that was accurate six months ago can drift after application changes, parser updates, network redesign, or new user behavior. Review rules that suddenly stop firing as carefully as rules that fire too often.
Fortinet provides a rich rule model, but correlation quality still depends on disciplined assumptions. The strongest FortiSIEM rule narrows the right event population, groups the right entity, uses a threshold or sequence that matches the behavior, emits enough evidence for triage, and is monitored like production code after deployment.
