The approved title uses “detection rules,” but current FortiAnalyzer terminology centers on event handlers. Basic event handlers generate events when one of their rules matches, while correlation event handlers generate events when a sequence or combination of rules matches using operators such as AND, AND_NOT, OR, FOLLOWED_BY, and NOT_FOLLOWED_BY. FortiAnalyzer includes predefined handlers, lets teams clone or build custom handlers, and can receive FortiGuard SOC Automation content packages containing updated event handlers, parsers, reports, connectors, and playbooks.
Within Fortinet Security Operations, detection engineering should therefore be designed around event-handler logic, Analytics log coverage, reusable data selectors, notification profiles, MITRE mapping, and downstream incident/automation workflows.
FortiAnalyzer Log Forwarding covers the movement of logs to other systems. This page focuses on how FortiAnalyzer turns logs into security events.
Basic handlers are OR-based event detectors
A basic event handler can contain several rules; an event is generated when one rule matches according to current FortiAnalyzer behavior.
Use basic handlers for single-event or repeated-event patterns that do not need an ordered sequence.
Keep each rule focused enough that an analyst can understand why the event fired from the matching log evidence.
Correlation handlers express multi-event sequence logic
Correlation handlers can combine conditions with AND, AND_NOT, OR, FOLLOWED_BY, and NOT_FOLLOWED_BY relationships.
This is useful for patterns such as repeated authentication failures followed by success, exploit event plus outbound connection, or missing expected activity after a precursor.
Define an appropriate time window so unrelated events are not accidentally stitched into one detection.
Event handlers evaluate Analytics logs, not Archive-only logs
Current FortiAnalyzer documentation is explicit: event handlers generate events from Analytics logs and not Archive logs.
Retention and storage mode therefore affect detection capability.
If a device/log type is stored only as archive and not available in Analytics, creating a perfect event handler will not make it detect that data.
Data selectors make scope reusable
Data selectors define devices, subnets, and filters used by handlers.
Separate the “which telemetry is in scope” decision from detection logic so one selector can be reused across several handlers.
Use narrow selectors for high-value environments and test that new devices are added to the appropriate selector after onboarding.
Notification profiles keep response routing separate
Notification profiles define where event notifications are sent.
This avoids hard-coding email/syslog/integration destinations in every handler.
Centralize notification routing and verify delivery latency, especially when handlers are intended to wake an on-call analyst rather than merely populate the event console.
Predefined handlers are content, not unquestioned truth
FortiAnalyzer provides predefined handlers for FortiGate, FortiSandbox, FortiMail, FortiWeb and—through Security Fabric/FortiGuard content—additional integrations.
Some predefined handlers are disabled by default.
Review conditions, expected data, severity, and local false positives before enabling; clone a handler when customization is needed rather than editing content you expect to receive future vendor updates for.
FortiGuard SOC Automation content updates detection coverage
Current FortiAnalyzer 7.6 exposes content packages from FortiGuard Security Automation Service, with objects such as event handlers, parsers, reports, connectors, and playbooks.
In 7.6.2+, the event-handler UI includes an Origin field that can identify built-in, custom, or FortiGuard content.
Track content-pack version changes because new parsers or handlers can alter alert volume without a local rule edit.
MITRE ATT&CK mapping helps coverage review
Custom handler attributes can include MITRE techniques, and FortiAnalyzer SOC workflows provide ATT&CK-oriented coverage views.
Use mapping to identify missing attacker techniques relevant to your environment.
Do not create low-confidence detections solely to fill ATT&CK cells; coverage without quality creates more triage cost than protection.
Automation Stitch can connect detection to response
FortiAnalyzer handlers can integrate with Automation Stitch and incident creation depending on configuration.
Use automated response for deterministic actions such as notification, ticket creation, enrichment, or narrowly scoped containment.
For destructive actions, require high-confidence detections and approval paths; one noisy event handler should not quarantine half the environment.
Detection rules need versioning and testing
Export/import support lets teams move custom event handlers between ADOMs or FortiAnalyzer units.
Keep rule definitions and rationale in source control or a detection repository, test changes against representative Analytics logs, and compare expected versus actual event counts.
Use SIEM Triage principles to tune handlers based on analyst dispositions.
FortiAnalyzer detection succeeds when event-handler content stays tied to healthy Analytics data
The mature SOC understands basic versus correlation logic, verifies Analytics log availability, reuses selectors/notifications, monitors FortiGuard content changes, maps meaningful ATT&CK coverage, and automates response cautiously.
Detection engineering is effective when FortiAnalyzer events are specific enough to drive investigation, not when every log becomes an event.
Handler design should begin with the event outcome analysts need. A handler that only says ‘log matched’ forces the SOC to reopen raw logs and rediscover the condition. Use event names, message templates, tags, severity, indicators, and MITRE context to surface the key entity and behavior in the generated event without overloading it with irrelevant fields.
Grouping logic is crucial in basic handlers. Current custom-handler workflow lets analysts choose fields that group logs before recurrence conditions are evaluated. Group by the entity that represents one attack—source IP, username, destination, device, session—so ten failures from ten unrelated users are not mistaken for one brute-force pattern.
Thresholds should be calibrated against real traffic. Authentication, IPS, email, and web events have different normal rates by environment. Test candidate handlers against several weeks of Analytics logs including maintenance, vulnerability scanning, backups, and user peaks before setting recurrence counts or event severity.
Correlation sequences need well-chosen NOT and FOLLOWED_BY logic. A successful login after failures can be suspicious, while the absence of an expected follow-up can also matter. Keep time windows tight enough to represent one attack chain and document ordering assumptions so analysts understand why two events became one correlation event.
ADOM design affects detection administration. Each ADOM has its own event handlers and event lists, so a handler created in the wrong ADOM can leave another tenant/domain unprotected. Standardize which handlers are global/shared versus ADOM-specific and use import/export to deploy common content consistently.
Analyzer-Collector architectures need rule execution awareness. Current FortiAnalyzer guidance states that the Analyzer evaluates event handlers in Analyzer-Collector collaboration. Ensure Analytics logs reach the Analyzer with enough timeliness/capacity for detections; a Collector having raw data is not sufficient if the central evaluation path is delayed.
Parser quality is a prerequisite for third-party detection content. Security Automation Service can deliver FortiGuard log parsers and event handlers for third-party products, but source-version changes can break parsing. Monitor parser errors and field population before blaming the event handler for missing detections.
FortiGuard content should be staged or reviewed after package updates. New event handlers may be disabled/enabled depending on package/product behavior, and updated parsers can change field semantics. Track content pack version and compare event volume after updates so the SOC can distinguish new threat activity from detection-content change.
Custom handler exceptions should be implemented through precise filters rather than globally disabling a useful detection. If a scanner or service account produces legitimate high-volume failures, exclude that known entity while leaving the handler active for other sources. Review exclusions on a cadence because scanners, accounts, and addresses change.
Detection metrics should include handler hit rate, true/false positive dispositions, top entities, incident conversion, automation actions, and time from source event to generated event. Handlers with chronic zero hits or overwhelming benign volume should be reviewed, not left indefinitely because they came from a vendor content pack.
Event severity should reflect both rule confidence and potential impact. A high-volume login anomaly may deserve Medium until corroborated by successful access or privileged target, while one highly specific malicious-IP intrusion can be High. Tune severity so escalation queues remain meaningful.
Incident auto-creation should be selective. Creating an incident for every event handler can flood FortiAnalyzer case management. Use handler settings and correlation logic so only detections that require investigation become incidents; lower-confidence signals can remain events or feed hunts.
Handler imports should be validated against ADOM device types and log schemas. A rule developed in one Security Fabric ADOM may reference fields or log categories unavailable in another. Test after import before enabling to avoid silent zero-hit rules.
Event-handler health should be reviewed after firmware upgrades. Field names, log IDs, parsers, and predefined content can change. Compare event rates and run known test events after major FortiOS/FortiAnalyzer upgrades so detection continuity is part of the upgrade acceptance criteria.
Detection governance should include a review owner and expiry date for every custom handler. Rules often outlive the device, threat, or log source that justified them. A quarterly review of zero-hit, high-noise, and ownerless handlers keeps FortiAnalyzer content focused and reduces analyst fatigue.
Known-good test events should be retained for critical detections. After parser, FortiAnalyzer, or FortiOS upgrades, replay or reproduce representative logs and verify that the expected event/incident still appears with the right severity and fields. This converts upgrade acceptance from ‘logs are arriving’ to ‘security logic still works.’
Review handler health continuously.
A detection rule should document the event fields and log sources it assumes. If log normalization, device configuration, or retention changes, the rule owner needs a way to see that the detection has lost visibility before an incident exposes the gap.
