FortiAnalyzer distinguishes raw logs from events and incidents. Logs are individual records generated by devices and services. Event handlers evaluate those records for conditions that matter. Events represent meaningful detections. Incidents organize higher-level investigation and response around security activity that deserves analyst attention.

The NSE 5 FortiAnalyzer 7.6 Analyst covers logs, events, incidents, event handlers, indicators, and Security Fabric analytics. The critical skill is understanding how a detection moves from telemetry to an analyst case and how to tune each layer so the SOC receives useful signals rather than a flood of unprioritized records.

Event handlers convert conditions into detections

A basic event handler contains rules that are evaluated against matching logs. Fortinet documents that rules in a basic handler have an OR relationship: if one of the configured rules matches, an event can be generated according to the handler configuration.

Basic handlers are useful when a single condition is meaningful on its own, such as a specific high-severity security log, a threshold, or a field value that represents a known risk. They are easier to reason about because the trigger logic is direct.

The main tuning challenge is scope. A broad condition may produce thousands of events from normal activity. A condition that is too narrow may miss variations of the same attack. Start with the security question the handler is meant to answer and tune the filters against real log data.

Correlation handlers model sequences and combined conditions

Correlation handlers can combine multiple rules and logical relationships. FortiAnalyzer supports operators such as AND, OR, AND_NOT, FOLLOWED_BY, and NOT_FOLLOWED_BY in correlation logic. This allows the detection to represent a pattern rather than a single record.

For example, repeated authentication failures followed by a success from the same source can be more interesting than either condition alone. A correlation sequence can encode that relationship and reduce the number of isolated events an analyst must mentally connect.

Correlation also increases complexity. Time windows, entity fields, sequence order, and missing data all affect whether the pattern matches. Test correlation logic with known data before enabling aggressive response automation.

Normalized logs broaden correlation possibilities

FortiAnalyzer 7.6 can use normalized SIEM data for event handling in supported Security Fabric ADOM workflows. This matters because normalized fields let handlers reason about similar attributes across multiple products without depending entirely on vendor-specific log syntax.

A handler that expects normalized fields will not work correctly if the source log is unparsed or its parser is disabled. When a correlation rule seems silent, confirm the underlying logs and normalized fields before changing the rule logic.

This is why SIEM normalization and detection engineering are inseparable. Detection quality depends on both the rule and the data model feeding it.

Notification profiles are separate from detection logic

Fortinet separates event-handler logic from notification profiles. A handler determines when an event is generated; a notification profile determines how alerts can be sent through configured channels such as email, SNMP, syslog, or supported connectors.

Keeping these concerns separate is useful operationally. The SOC can change escalation destinations without rewriting detection logic, and the same detection can use different notification behavior in different environments.

Do not treat notification delivery as proof that detection worked correctly. An event can be valid even if a downstream notification integration is broken. Troubleshoot detection and delivery as separate stages.

Incidents organize investigation around meaningful activity

An incident is a higher-level SOC object used to organize security activity, context, and analyst work. FortiAnalyzer 7.6 includes incident-analysis capabilities, indicators, outbreak-related workflows, and a SOC dashboard that can pivot analysts into incident detail.

The incident layer is where context becomes important: affected assets, users, indicators, event history, severity, category, and response status. Analysts can move from “this rule fired” to “what happened, what is affected, and what should we do?”

A strong incident process also records disposition. False positive, expected administrative behavior, contained threat, unresolved investigation, and confirmed compromise are different outcomes. Closing everything as “resolved” without context destroys the feedback that detection engineering needs.

Indicators help connect related evidence

Indicators such as suspicious IP addresses, domains, hashes, or other observables can enrich an incident and support automation. FortiAnalyzer can integrate indicator context with its SOC workflows, and playbooks can use indicators for enrichment or response when connectors are configured.

Indicators should not be treated as permanent truth. Reputation changes, shared infrastructure produces false positives, and some indicators have short useful lifetimes. Record source, confidence, first/last observed time, and the reason an indicator is relevant to the incident.

This discipline prevents the SOC from turning a historical observation into an indefinite block that creates future business impact.

Tuning begins with event volume and analyst value

A handler that fires constantly may be technically correct and operationally useless. Review event volume, affected entities, duplicate patterns, and analyst closure outcomes. If most events are benign, refine the condition, add context, adjust thresholds, or use correlation to require stronger evidence.

Do not tune only by lowering sensitivity. Some high-volume detections reveal a real configuration weakness that should be fixed at the source. The SOC should decide whether to change the detection or change the environment based on the underlying risk.

The incident response process should define which event categories demand immediate action, which can be queued, and which are informational. Detection tuning is partly a technical task and partly an operational-priority task.

Troubleshoot missing events from the data backward

If an expected event is missing, verify that the source log exists in the relevant time window. Confirm the fields used by the handler are populated and, for normalized rules, confirm the parser inserted the record into the SIEM database. Then verify the handler is enabled and its filters match the actual field values.

For correlation handlers, also inspect rule order, time relationship, entity matching, and negative conditions. A NOT_FOLLOWED_BY rule can fail simply because the observation window has not completed yet.

If the event exists but no incident or notification appears, move to the next stage rather than rewriting the handler. Layered troubleshooting preserves the evidence that shows which component actually failed.

Detection quality improves through case feedback

The SOC should feed incident outcomes back into event-handler design. Repeated false positives reveal filters that need context. Missed detections reveal fields or sequences that the handler did not represent. Successful detections reveal patterns worth reusing across similar environments.

FortiAnalyzer provides the technical chain from log to event to incident, but the organization supplies the learning loop. Analysts who investigate cases are often the best source of information about which detection details were useful and which were noise.

A mature deployment therefore treats event handlers as maintained detection content, not one-time configuration. Version them, test changes, measure their output, and retire obsolete rules. That is how centralized analytics becomes an adaptive SOC capability rather than a static alert generator.

Severity should be earned by evidence. If a handler marks every matching event as critical, the incident queue quickly loses prioritization value. Severity can reflect threat confidence, asset importance, user privilege, exploit stage, or other context that helps analysts decide which detections deserve immediate attention.

Deduplication and grouping strategy matter as well. Hundreds of identical events for the same host may represent one continuing condition rather than hundreds of independent incidents. Event and incident design should preserve useful frequency information without forcing the analyst to close repetitive cases one by one.

Incident ownership should be explicit. Assign cases to an analyst or team, record status and next action, and use handoff notes when a shift changes. Technical context loses value if nobody knows who is responsible for moving the investigation forward.

Outbreak and threat-intelligence context can raise the priority of activity that would otherwise look routine. FortiAnalyzer 7.6 includes outbreak-related workflows and indicator enrichment capabilities; use external context to sharpen investigation, but preserve the local evidence that shows whether the environment was actually affected.

After a significant incident, compare the final timeline with the original handler logic. Ask which log first contained decisive evidence, how long it took to become an event, whether the incident grouped the right context, and what the analyst had to search manually. Those answers identify the next improvements to parsing, detection, and case automation.

Event naming and categorization should be stable enough for automation and reporting. If handlers use inconsistent categories for similar behavior, the SOC dashboard and incident metrics become fragmented. Create a small taxonomy for detection families, severity, and ownership so analysts can recognize related cases quickly.

Suppression requires caution. Temporarily muting a known noisy source can protect analyst attention during maintenance, but permanent suppression can hide a real attack that uses the same pattern later. Record the reason, scope, and expiry of any exception and review it when the underlying system changes.

Detection engineering should also consider negative evidence. A NOT_FOLLOWED_BY condition can be valuable when a normal follow-up action fails to appear, but these rules depend heavily on timing and complete telemetry. Validate the observation window and source reliability before treating absence as proof of malicious behavior.

Handlers should be reviewed when source products or parsers change. A renamed field, new log subtype, or altered severity value can silently reduce match rates even though the handler remains enabled. After upgrades, replay or generate representative events and confirm that critical detections still create the expected incidents and notifications.

Even a two-word field change can break a detection path, so treat post-upgrade validation as a release gate for high-value handlers. Maintain a small set of known-good test cases that prove the event, incident, severity, and notification behavior end to end before declaring the analytics stack fully operational.