FCP FortiAnalyzer 7.4 key terms

A logical partition on FortiAnalyzer that isolates device configurations, logs, and reports from other partitions. Each ADOM has its own administrators, event handlers, and data retention, letting one appliance serve multiple customers or business units.

A per-ADOM setting controlling whether the ADOM collects data itself. Normal mode is active and receives logs; backup mode holds a standby copy used for HA or migration, and does not process new logs.

A special read-only ADOM that aggregates configuration objects, such as address and service definitions, from all other ADOMs. It provides a single view for centralized policy and object management without storing device logs.

A deployment of two or more FortiAnalyzer units sharing a cluster IP so that one takes over log reception and reporting if its peer fails. Modes include standalone, primary, and secondary, with configuration and data synchronized between nodes.

The shared address assigned to a FortiAnalyzer HA cluster. FortiGate devices send logs and administrators connect to this IP, so failover does not require reconfiguring log destinations or management sessions.

A feature that links multiple FortiAnalyzer units, including HA clusters, into one management view. Administrators can see devices, logs, and incidents across all members from a single console.

The authenticated, encrypted link that joins FortiAnalyzer units in a fabric. It is established by exchanging authorization codes between members and is required before cross-unit log search or incident sharing works.

A permission template that defines what an administrator account can view and change, such as read-write or read-only access to specific ADOMs, reports, log views, or system settings. Profiles enforce role separation.

Programmatic access to FortiAnalyzer through HTTPS endpoints, authenticated by an API token or administrator credentials. It supports tasks such as adding devices, running log searches, and exporting reports.

The maximum storage allocated to an ADOM or device for log data. When the quota is reached, FortiAnalyzer deletes the oldest logs or stops accepting new ones, so sizing quotas correctly protects availability.

A policy that sets how long logs are kept before automatic deletion, defined per ADOM or log type in days or by storage size. It balances forensic and compliance needs against disk capacity.

The primary database area where FortiAnalyzer indexes received logs for searching, reporting, and event correlation. Data here is queryable in real time but is subject to disk quota and retention limits.

A secondary storage area, typically on a remote server or separate disk, where logs are copied for long-term retention. Archived logs are not directly searchable and must be restored before analysis.

A FortiAnalyzer setting that relays received logs to another destination, such as a syslog server, SIEM, or another FortiAnalyzer. Forwarding rules can filter by device, log type, and severity.

The format used when FortiAnalyzer forwards logs to external collectors. Options include default, CSV, and CEF, and the choice must match what the receiving SIEM or syslog server can parse.

The process of consolidating logs from many devices into a single ADOM or collector for unified search and reporting. Aggregation simplifies correlation but increases the load on the receiving unit.

A FortiGate or other Fortinet product that has been authorized to send logs to FortiAnalyzer, usually by adding it in the device manager or accepting its serial number. Only registered devices can be monitored and reported on.

A FortiAnalyzer feature that listens for logs from unknown devices and lets the administrator approve them, automatically creating device entries. It reduces manual registration in large environments.

The origin of a log record, identified by device serial number, hostname, or IP address. Accurate source identification is needed for per-device quotas, reports, and event correlation.

The rule set that decodes raw log text into structured fields such as source IP, user, action, and severity. Parsers differ by log type, and a correct parser is required for search and report accuracy.

A category that describes what a log record represents, for example traffic, event, attack, or content. FortiAnalyzer uses log type to select the parser, storage area, and available report datasets.

A user-defined parsing rule created for non-standard or third-party syslog formats. It maps raw message content to indexed fields so that custom sources can be searched and reported consistently.

The query interface for finding log records using free text and field filters, such as source IP, policy ID, or severity. Results can be saved, exported, or turned into report datasets.

A saved SQL query that defines which log records a report chart or table uses. Datasets can be built from templates or written manually, and they are the foundation of every custom report.

A reusable layout that defines which datasets, charts, and text appear in a generated report. Templates are bound to an ADOM and can be scheduled to run automatically at set intervals.

A configuration that runs a report template automatically at a chosen time and frequency, then delivers the output by email or file. Schedules ensure regular reporting without manual generation.

A saved set of delivery options for generated reports, such as email recipients, file format, and storage location. Applying one profile to a schedule keeps distribution consistent across reports.

A visual element inside a report, such as a bar, pie, or time-series graph, populated by a dataset. Chart type and filters determine how log trends are presented to readers.

A placeholder in a report template that is replaced at generation time, for example the device name or report period. Macros make one template reusable across devices and time ranges.

A tracked security event or group of related events that requires review. Incidents carry status, severity, and assigned handlers, and they can be generated automatically by event handlers or created manually.

A rule that watches incoming logs for a pattern, such as a threshold of failed logins, and triggers an action like raising an incident or sending an alert. Handlers are scoped to an ADOM.

The process of combining multiple log records or events to detect a condition that no single record reveals, such as repeated attacks from one source. Correlation rules drive automated incident creation.

The workflow state of an incident, typically new, in progress, and resolved, used to track investigation progress. Status changes are logged for audit and reporting on response performance.

The act of assigning an incident to a specific administrator or team for investigation. Assignment supports accountability and lets managers see workload and unresolved cases.

An automated sequence of actions triggered by an incident or event, such as gathering logs, running a query, or sending notifications. Playbooks reduce manual effort and standardize response steps.

A single task executed by a playbook or automation rule, for example sending an email, running a CLI script, or creating an incident. Actions are chained to build response workflows.

The condition that starts an automation rule or playbook, such as a new incident matching a severity or a specific event type. Triggers connect detection to automated response.

A proactive investigation approach using log search, indicators, and correlation to find hidden compromise rather than waiting for alerts. On FortiAnalyzer it relies on flexible queries and saved searches.

A piece of evidence suggesting compromise, such as a malicious IP, domain, or file hash. FortiAnalyzer can match IOCs against logs to surface affected devices during investigation.