NSE6_FSM_AN-7.4 Practice Questions

In FortiSIEM, performance monitoring thresholds define specific operational limits that trigger system alerts when resource metrics, such as CPU utilization, memory usage, or disk space, breach designated baselines. FortiSIEM supports both global and per-device thresholds for performance metrics to manage monitoring efficiently. Global thresholds establish a system-wide default policy applied across all discovered and monitored devices. To accommodate specialized infrastructure requirements, administrators can configure per-device thresholds that override global settings for specific devices. This dual-layer architecture ensures consistent baseline monitoring across the entire network infrastructure while providing the technical flexibility required to customize thresholds for high-performance servers, critical network devices, or specialized security appliances without affecting other systems.

A: FortiSIEM thresholds are fully customizable by administrators and are not hardcoded or fixed values.

B: FortiSIEM uses security rules for security events, whereas thresholds apply to performance metrics.

D: FortiSIEM allows device-specific thresholds to override global defaults, so it does not rely exclusively on global thresholds.

- Fortinet FortiSIEM 7.0.0 Administration Guide

Section: "Configuring Performance Thresholds"

pp. 412-415.

- Fortinet FortiSIEM 7.1.0 User Guide

Section: "Metrics and Performance Threshold Configuration".

In FortiSIEM Machine Learning features, including baseline profiling and User and Entity Behavior Analytics, execution run modes dictate how analytical models are trained and executed. The Local Auto run mode requires the most processing time because it performs fully automated hyperparameter tuning and model optimization locally on the FortiSIEM supervisor or worker nodes. Unlike standard execution modes that rely on default static parameters, Local Auto runs continuous parameter grid searches, extensive cross-validation, and repeated iterative model evaluations to dynamically optimize accuracy for the specific environment. Consequently, this intensive local computational workflow demands significant CPU and memory resources, resulting in the longest execution time among all available ML run modes.

B: Local mode uses default, pre-configured hyperparameters without running exhaustive tuning searches, completing faster than Local Auto.

C: Forecasting is an analytical baseline calculation method, not an automated hyperparameter-tuning ML run mode.

D: Regression is a mathematical algorithm classification, not a FortiSIEM execution run mode setting.

- Fortinet FortiSIEM 7.0.0 UEBA and ML Guide

Section: "Configuring Machine Learning Run Modes"

pp. 28-31.

- Fortinet FortiSIEM 7.1.0 Analytics Guide

Section: "Machine Learning Profile Execution Settings".

In FortiSIEM Analytics, when configuring a nested query using the IN operator, the outer query attribute must match the data type and semantic identity of the inner query or referenced CMDB attribute. In the exhibit, the outer query specifies the attribute User (string), but references an inner CMDB attribute of Device IP (IP address) from Device IP: Server Inventory. Because an IP address and a username belong to incompatible data types, the query logic fails to produce any valid matches, resulting in zero search results. To resolve this, the outer attribute must be set to an IP-based attribute (such as Source IP or Reporting IP), or the inner subquery attribute must output user identities.

A. The Time Range is set incorrectly:

A relative time range of "Last 10 Days" is syntactically valid and standard in FortiSIEM Analytics searches, so it does not prevent query execution.

C. You cannot reference User and Event Type attributes in the same search:

FortiSIEM fully supports filtering across diverse event attributes—including User and Event Type—simultaneously within a single analytics search filter.

D. The Boolean operator is wrong between the attributes:

Using the AND operator between filter conditions is correct and standard practice to narrow events down to failed logons matching specific criteria.

Fortinet Document Library: FortiSIEM 7.4.0 User Guide, Section: "Analytics" — Creating a Nested Search & Filter By Criteria.

Fortinet Document Library: FortiSIEM 7.4.0 User Guide, Section: Structured Search Operators and Attribute Types.

Fortinet Training Institute: FortiSIEM 7.4 Analyst Study Guide, Module: Analytics Searches, Section: "Nested Queries and Attribute Type Alignment".

In FortiSIEM Analytics, configuring a Group By condition aggregates incoming events that share identical values across all specified grouping attributes into a single result row.

Evaluating the three attributes—Reporting Device, Reporting IP, and Application Category—across the six events yields the following distinct sets:

1. (FW01, 10.1.1.1, DB) — shared by Row 1 and Row 5
2. (FW02, 10.1.1.2, WebApp) — Row 2
3. (FW01, 10.1.1.1, SSH) — Row 3
4. (FW03, 10.1.1.3, DB) — Row 4
5. (FW04, 10.1.1.4, SSH) — Row 6

Because Row 1 and Row 5 match across all three grouping attributes, they are combined into one row, resulting in five displayed records.

A. Four: Incorrectly assumes another duplicate exists; only Row 1 and Row 5 share matching values across all three grouped fields.

C. One: Collapsing to a single row would require all six events to share the exact same Reporting Device, IP, and Application Category.

D. Six: Reflects the total count of unaggregated raw events, failing to group and consolidate the duplicate values of Row 1 and Row 5.

E. Two: Erroneously groups by a non-specified attribute or drastically under-counts the five distinct multi-attribute combinations present in the table.

Fortinet Documentation Library, FortiSIEM 7.4.0 User Guide, Section: "Analytics – Structured Historical Search and Attribute Grouping", pp. 162–165.

Fortinet Training Institute, FortiSIEM 7.4 Analyst Study Guide (NSE 6 / FCSS), Module 2: "Event Analytics and Rule Conditions", Section: "Group By and Aggregation Mechanics", pp. 78–82.

Fortinet Documentation Library, FortiSIEM Online Help, "Historical Search Syntax and Event Attribute Grouping Rules: Result Set Consolidation".

Silberschatz, A., Korth, H. F., & Sudarshan, S., Database System Concepts (7th ed.), McGraw-Hill, Chapter 3: "SQL and Aggregation Operators", pp. 93–98. DOI: 10.1145/333107.333108.

In FortiSIEM Analytics and User and Entity Behavior Analytics (UEBA) search configurations, filter conditions rely on exact attribute-operator syntax to accurately target specific user actions. To isolate events generated by a specific user such as JSmith, the User attribute combined with the exact-match operator IS (i.e., User IS jsmith) is utilized. This precise condition ensures that the analytics engine maps the failed login event directly to the specified target identity without catching unrelated accounts or partial string matches. Applying this targeted condition guarantees that UEBA risk scoring and tag assignments are correctly evaluated against the intended user account within FortiSIEM's analytics framework.

A. User = smith: This evaluates the username "smith" instead of "jsmith", failing to target the specified user's failed login events.

B. Username NOT END WITH jsmith: This negative match condition explicitly excludes events associated with jsmith rather than selecting them for tag application.

D. Username CONTAIN smit: This uses an overly broad substring match that incorrectly captures unrelated users containing "smit" such as "smithson".

1. Fortinet FortiSIEM 7.4.0 Technical Documentation

"Analytics Search and Filter Syntax"

Chapter: User and Entity Behavior Analytics.

2. Fortinet FortiSIEM 7.4.0 User Guide

Section: "Configuring Analytics Rules and UEBA Tags".

In FortiSIEM rule configuration, the Incident Attributes defined in the Incident Generator determine which fields define the identity of an incident and populate dynamic variables in the Incident Title. The attributes available for selection under the Filter Attribute dropdown are populated strictly from the Group By (aggregation) conditions configured in the rule's subpattern. If an event attribute such as Destination Host Name is not defined as an aggregate item within the triggering subpattern, FortiSIEM cannot group events by it, nor can it map it as an incident attribute. Therefore, Destination Host Name must be added as an aggregate item in the subpattern to be available for selection.

A: Triggered Attributes only define which raw event details appear in dashboards and incident analytics; they do not expose attributes for incident mapping or title substitution.

C: Event Types categorize log formats and event families in the CMDB; adding one does not configure subpattern fields or enable an attribute in the Incident Generator.

D: FortiSIEM rules permit multiple concurrent incident attributes; removing Destination IP is completely unnecessary and does not make Destination Host Name available in the list.

Fortinet Document Library: FortiSIEM 7.4.0 User Guide, Section: "Rules" — Defining the Incident Generated by a Rule (Topic: Setting Incident Attributes from Subpattern Group By Criteria).

Fortinet Document Library: FortiSIEM 7.4.0 Online Help, Section: Analytics & Rules Engine — Sub-topic: "Configuring Rule Subpattern Aggregations and Group-By Fields".

Fortinet Training Institute: FortiSIEM 7.4 Advanced Analytics Study Guide, Lesson 4: "Incident Creation and Rule Architecture," Subsection: "Subpatterns and Incident Attributes Configuration."

In FortiSIEM Machine Learning, regression models (such as DecisionTreeRegressor) map input feature metrics—here AVG(Memory Util), AVG(Sent Bytes64), and AVG(Received Bytes64)—to predict a target metric, AVG(CPU Util). When an analyzed device exhibits consistently elevated memory utilization over time, scheduled model retraining incorporates this persistent behavior into the feature dataset. Rather than treating a permanent operational change as a perpetual anomaly, FortiSIEM updates the regression model with the higher average memory utilization value to establish the new operational baseline for future target predictions.

A is incorrect: FortiSIEM trains decision tree regression structures and statistical model artifacts rather than maintaining or updating "regression tables" for predictor variables.

B is incorrect: The configured model predicts CPU utilization rather than alerting directly on memory, and persistent behavior is incorporated into the baseline rather than triggering recurring incidents.

C is incorrect: FortiSIEM evaluates anomalies using fixed deviation thresholds between predicted and observed values; it does not dynamically lower trigger requirements for CPU utilization.

Fortinet Training Institute, FortiSIEM 7.4 Analytics Course Study Guide, Module: "Machine Learning and Baseline Profiling", Section: "Regression Models and Feature baselines".

Fortinet Documentation Library, FortiSIEM 7.4.0 User Guide, Section: "Machine Learning", Sub-section: "Configuring Regression-Based Predictions and Model Updates".

Fortinet Documentation Library, FortiSIEM 7.4.0 Online Help Reference: Machine Learning Rule and Model Management, Section: "DecisionTreeRegressor Task Parameters".

FortiSIEM applies tags to FortiClient EMS-managed hosts through FortiEMS integration. The

FortiSIEM 7.4 User Guide states that FortiSIEM supports discovery of FortiEMS servers using the

FortiEMS Management Server API with username/password authentication. That supports option A:

FortiEMS API credentials must be configured on FortiSIEM. The same guide explains that after

FortiEMS discovery, “FortiSIEM can tag or untag a host, using classification tags on FortiEMS server.”

It further explains the ZTNA workflow: in ZTNA, these tags are imported by Fortinet devices,

especially FortiGate firewalls, and referenced in ZTNA firewall rules. That supports option C: the tag

value used for ZTNA classification must be available/defined for the FortiEMS tagging workflow.

Option B is not the best required configuration in the question because a remediation script is an

execution method, not one of the two foundational settings being asked for. Option D reverses the

API relationship; FortiSIEM connects to FortiEMS using FortiEMS credentials, not FortiSIEM API

credentials stored on EMS.

In FortiSIEM, rules are constructed using specific mandatory and optional configuration components within the Rule Builder. When defining a rule, every rule must contain at least one Subpattern (which specifies the event filters, aggregate conditions, group-by attributes, and evaluation time window required to match incoming log events) and a designated Detection Technology (such as Log/Event-based, Statistical, or Machine Learning). Without these two mandatory building blocks, a rule cannot evaluate incoming event streams or generate incidents. In contrast, exception policies and clear policies are optional settings used to override rule actions or automatically resolve incidents under specified conditions.

Option A: An exception policy is an optional rule setting used to exclude specific benign events or behavior from triggering incident generation.

Option D: A clear policy is an optional rule component that defines criteria for automatically setting an open incident state to cleared.

- Fortinet Documentation Library

FortiSIEM 7.1.0 Rule Overview and Configuration Guide

Section: "Rule Architecture and Subpatterns"

pp. 112-115.

- Fortinet Technical Documentation

FortiSIEM Analytics and Rules Engine Reference Guide

Document ID: 08-700-814041-2023

Section: "Defining Rules and Subpatterns".

In FortiSIEM Analytics, selecting Group By attributes aggregates all incoming events that share identical values for the specified attributes into a single result row. In this query, grouping is performed on both the User and Count attributes.

Evaluating the six events yields the following (User, Count) combinations:

1. (Mike, 4)
2. (Bob, 3)
3. (Alice, 2)
4. (Alice, 2)
5. (Bob, 6)
6. (Mike, 5)

Rows 3 and 4 contain identical values (Alice and 2), which FortiSIEM collapses into a single row. The remaining four combinations are unique, resulting in a total of five displayed rows.

A. Two: This would require only two unique User/Count attribute combinations, whereas the exhibit yields five distinct pairings.

B. Six: Six results would display only if all rows were distinct or unaggregated; here, the identical Alice/2 entries combine into one.

C. Three: Three results would display if the query grouped solely by the User attribute (Mike, Bob, Alice), ignoring the Count attribute.

E. One: One result would occur only if all six log entries shared identical User and Count values, which is not the case.

Fortinet, FortiSIEM 7.4.0 User Guide, "Analytics" > "Running an Analytics Query" > "Group By and Aggregation", Fortinet Document Library.

Fortinet, FortiSIEM 7.2.0 Analytics Guide, "Running a Historical Analytics Query" > "Group By Attributes", p. 21.

Fortinet Training Institute, FortiSIEM 7.4 Analyst Study Guide, Lesson: "Analytics and Reports", Section: "Group By Behavior and Result Tables".

Fortinet, FortiSIEM 7.4.0 Reference Guide, "Search and Query Syntax" > "Display and Grouping Attributes", Fortinet Document Library.