FortiAnalyzer can support a security operations center by connecting telemetry, detections, incident records, analyst investigation, and automation. In FortiAnalyzer 7.6, the SOC Dashboard summarizes incidents, events, outbreak alerts, affected users, compromised hosts, and connector health; Incidents & Events provides the working area for triage; and playbooks can automate selected actions through connectors. The currently available FortiAnalyzer 7.6 Analyst path aligns directly with this operational role.
A mature workflow does not automate every alert. It separates collection, detection, triage, investigation, containment, recovery, and review so each stage has evidence and an owner. FortiAnalyzer can accelerate several of those stages, but the analyst still needs to understand why an event matters, how much confidence the evidence supports, and whether an automated action is safe for the affected asset.
Use the SOC Dashboard for prioritization, not final conclusions
The SOC Dashboard provides a high-level view of activity, including high-severity incidents, outbreak alerts, affected users, compromised hosts, events, incident categories, and connector health. Those widgets are useful for deciding where to look first, especially during shift handover or a sudden increase in alerts.
A dashboard count is not the investigation itself. A spike in incidents can come from one noisy source, a new detection, a genuine attack, or a configuration change. Analysts should pivot from the widget into the underlying Incidents & Events data and examine the affected assets, timestamps, rule or handler, supporting logs, and related indicators.
Time range matters during that pivot. Comparing a current spike with the preceding hour, day, or week can show whether the activity is anomalous or part of a recurring pattern. Keep operational baselines so the dashboard is interpreted in context rather than by severity color alone.
Triage events using scope, confidence, and impact
Initial triage should establish what happened, which assets and users are affected, how reliable the detection is, and what business impact is possible. Severity from an event handler is an input to that decision, not a substitute for it. A medium-confidence event on a domain controller may deserve faster attention than a high-severity event on an isolated test system.
Useful questions include whether the source is internal or external, whether the behavior succeeded, whether multiple hosts show the same pattern, and whether the activity aligns with approved administrative work. The broader incident-response lifecycle is helpful because triage is the point where an alert becomes a controlled response rather than an unstructured search.
Analysts should record why the priority was chosen. That note supports shift handover and later review, especially when the case is downgraded or closed as benign. Without rationale, future analysts may repeat the same investigation every time the event appears.
Raise incidents when work needs ownership and history
FortiAnalyzer incidents provide a container for events, reports, comments, indicators, assignments, and audit history. Raising an incident is useful when an event requires investigation, coordination, or response beyond immediate validation. It turns a transient alert into an object that can be assigned and tracked.
Incident categories, status, and ownership should support the SOC process rather than mimic every detection type. A ransomware investigation, suspicious authentication pattern, and policy-violation case may require different runbooks even when they share some technical indicators. Keep the classification meaningful enough to select the right response path.
The incident record should preserve major analyst decisions: what evidence was reviewed, whether the activity was confirmed, what containment occurred, who approved disruptive actions, and why the incident was closed. This creates an operational timeline that can support post-incident review and audit.
Pivot from incident context into supporting logs
FortiAnalyzer lets analysts move from incident or event context back into related logs. That pivot is where a detection becomes a narrative. Start with the event time and affected asset, then examine traffic, authentication, security-profile, DNS, web, or system logs that could explain what happened before and after the detection.
Sequence matters. A malicious download, for example, may be preceded by DNS resolution and web access, followed by endpoint communication or command-and-control attempts. Looking only at the final blocked event can miss whether an earlier stage succeeded. Correlating several log types provides a stronger conclusion than relying on one signature.
Retain the exact filters or evidence references that support the finding. The goal is reproducibility: another analyst should be able to follow the same path and understand why the incident was confirmed or rejected.
Map detections to MITRE ATT&CK when it adds context
FortiAnalyzer can present incident and event information in relation to MITRE ATT&CK coverage. ATT&CK mapping can help analysts describe adversary behavior consistently and identify whether several detections represent stages of one campaign rather than unrelated alerts.
Technique labels should not be treated as proof of attribution. A behavior can map to a technique used by many threat actors, and benign administration can sometimes resemble an adversary technique. Use the mapping to organize evidence and identify investigation gaps, not to leap from one event to a named attacker.
Coverage views can also support detection engineering. If important techniques for the organization’s threat model have little telemetry or no handler coverage, that gap can guide new logging, event-handler, or endpoint-detection work.
Use playbooks for bounded, repeatable actions
FortiAnalyzer playbooks combine a trigger with one or more tasks performed through connectors. They can be launched on demand or run automatically when configured trigger conditions are met. This is useful for repeatable enrichment, notification, ticketing, or containment steps that would otherwise consume analyst time.
Automation should begin with low-risk actions. Enriching an IP or domain, attaching threat intelligence to an incident, collecting endpoint information, or notifying a channel is generally easier to govern than immediately quarantining a critical server. The principles in a structured incident-response playbook still apply: define inputs, decision points, actions, owners, and expected evidence.
Every automated task should have an observable result and failure path. If a connector is unavailable or returns incomplete data, the playbook should not create false confidence. Analysts need to know which tasks ran, what data they produced, and whether a manual step is required.
Use connectors to extend the response boundary carefully
FortiAnalyzer 7.6 provides connectors for Fortinet and third-party systems, including local FortiAnalyzer actions, FortiOS, FortiGuard, FortiManager, endpoint and security products, and generic integration patterns. Connectors let a playbook enrich or act on systems outside the log platform.
This capability makes permissions important. A connector that can quarantine an endpoint or modify a security control should use an account with only the privileges required for that action. Credentials and API tokens need secure storage, lifecycle management, and monitoring like any other privileged automation identity.
Test connector actions in a noncritical scope first. A correct API call with the wrong parameter can still disrupt production, and an automated containment step can amplify a false positive. Approval gates or on-demand playbooks are appropriate when the consequence of an incorrect action is high.
Measure workflow quality with response evidence
SOC performance is not simply the number of alerts closed. Useful measures include time to triage, time to containment for confirmed incidents, proportion of events that become actionable incidents, recurring false positives, automation success, and the number of cases returned because required evidence was missing.
On-call and shift practices matter as much as dashboards. The on-call incident response model emphasizes clear ownership and handoff. In FortiAnalyzer, incident assignment, comments, status, audit history, and attached evidence can support that continuity when teams work across shifts.
Review closed incidents for detection and automation improvements. If analysts repeatedly perform the same enrichment manually, it may be a playbook candidate. If one handler produces mostly benign cases, improve its data selector or correlation logic instead of accepting permanent alert fatigue.
Escalation criteria should be written before the incident is stressful. Define which severities, assets, threat categories, or business impacts require immediate notification to incident leadership, infrastructure teams, legal or compliance stakeholders, or business owners. FortiAnalyzer can organize the technical evidence, but the organization still needs a decision model for who may authorize containment.
Containment playbooks should distinguish reversible from destructive actions. Adding an IP block, isolating an endpoint, disabling an account, or changing a firewall policy can interrupt legitimate business activity. Prefer actions that can be reversed quickly, record their start and end time, and require human approval when the affected asset is critical or the detection confidence is limited.
Threat-intelligence enrichment is useful when it changes a decision. Looking up an indicator can provide reputation, context, or related threat information, but analysts should preserve the original observation and time. Reputation can change, shared infrastructure can host both benign and malicious activity, and an indicator match should be combined with local behavior before containment.
Shift handover should be treated as a workflow stage. Open incidents need a concise statement of current hypothesis, affected assets, evidence already reviewed, actions taken, pending tasks, and next decision. FortiAnalyzer incident comments and audit history can preserve this context, but only if analysts use them consistently instead of keeping key reasoning in private notes or chat messages.
Post-incident review should feed the platform. Convert lessons into better event-handler logic, clearer dashboards, revised escalation criteria, or safer playbook tasks. If an incident required a one-off query that would have shortened detection by hours, preserve that query or build the logic into a repeatable detection after validation. This closes the loop between response experience and future readiness.
Exercises are useful even without a live attack. Tabletop scenarios can walk analysts from a dashboard alert through triage, incident creation, log pivots, enrichment, containment approval, and closure. The exercise reveals missing permissions, ambiguous ownership, and automation assumptions before those weaknesses affect a real response.
Finally, retain metrics about automation itself. Track failed connector calls, playbook duration, manual overrides, and actions reversed after investigation. These measures show whether automation is reducing response work or merely moving failure into a less visible part of the workflow.
Routine practice helps analysts execute the workflow consistently when a real incident creates time pressure and incomplete information. Exercises should require analysts to justify priority, preserve evidence, document decisions, and hand off an unresolved case so the team rehearses the human process as well as the FortiAnalyzer interface.
Build a workflow analysts can explain under pressure
A useful FortiAnalyzer SOC workflow can be narrated from beginning to end: logs arrive from authorized devices, event handlers recognize a meaningful condition, the SOC Dashboard or event queue surfaces it, an analyst triages scope and impact, an incident records the investigation, supporting logs and indicators establish confidence, and playbooks automate only the actions that are safe and repeatable.
That sequence aligns with the SIEM operating model without reducing security operations to a product label. FortiAnalyzer supplies data and workflow capabilities; the SOC supplies threat hypotheses, business context, decision authority, and accountability.
For current FortiAnalyzer analysts, the durable skill is judgment supported by evidence. Know when to escalate, when to suppress, when to enrich, and when to contain. Automation should make those decisions faster and more consistent, not obscure them. A workflow that an analyst can explain, reproduce, and audit is more valuable than one that merely closes alerts quickly.