FCP_FSM_AN-7-2 Practice Questions

The FortiSIEM machine learning engine, as configured in the exhibit, is designed for User and Entity Behavior Analytics (UEBA). It establishes a dynamic baseline of normal behavior for monitored entities, such as devices. The "Device Performance" model learns metrics like CPU and memory utilization over a 7-day window, retraining every hour. When a device exhibits a consistently high memory utilization, this new pattern is incorporated into the training data. Over subsequent training cycles, the machine learning model will adjust its baseline to reflect this new, sustained behavior as the "new normal" for that specific device, effectively updating its model with a higher average value for memory utilization.

A. This is incorrect because the question is specific to memory utilization. While network metrics might be part of the same model, the primary update concerns the metric that has changed, not unrelated ones.

B. An incident might be triggered initially when the behavior is first detected as an anomaly. However, because the behavior is consistent, the model will learn it as the new baseline and stop triggering incidents.

C. A change in memory utilization does not directly influence the model's trigger requirements for a separate and distinct metric like CPU utilization. The baselines for different metrics are learned independently.

1. FortiSIEM 7.2.0 Concepts Guide

Page 113

Chapter: "UEBA"

Section: "Machine Learning".

The guide states

"FortiSIEM establishes a baseline of normal activity for users and devices by analyzing historical data over a period of time. The baseline is continuously updated as new data becomes available." This confirms that a consistent new behavior will update the baseline.

2. FortiSIEM 7.2.0 Administration Guide

Page 518

Chapter: "Machine Learning"

Section: "How Machine Learning Works".

The documentation explains

"FortiSIEM uses machine learning algorithms to learn the normal behavior of users and devices in your network... When FortiSIEM detects behavior that deviates significantly from the established baseline

it generates an anomaly event." This implies that if the behavior becomes the new norm

it will be integrated into the baseline and no longer be considered a deviation.

The 'group by' function in FortiSIEM aggregates events that share identical values for the specified attributes into a single result row. In the exhibit, all six events have the same values for 'User' (jsmith), 'Source IP' (10.0.1.10), and 'Count' (1). A literal interpretation of the question would mean all six events are combined into a single group, yielding one result.

However, 'One' is not an available option. This suggests a likely error in the question, where the non-unique attribute 'Count' was intended to be a unique attribute like 'Time'. As each event in the exhibit has a unique timestamp, grouping by 'User', 'Source IP', and 'Time' would create a unique group for each event, resulting in six distinct results.

A. Two: This would be the result if there were exactly two unique combinations of the grouping attributes in the dataset.

C. Three: This would be the result if there were exactly three unique combinations of the grouping attributes.

D. Five: This would be the result if there were exactly five unique combinations of the grouping attributes.

E. Four: This would be the result if there were exactly four unique combinations of the grouping attributes.

1. FortiSIEM 7.2.0 Analytics Guide

Page 21

"Running a Historical Analytics Query". The guide explains the "Group By" functionality: "The query will find all the unique values for the attributes you select

and display them in the query results." This confirms that the number of results corresponds to the number of unique combinations of the 'Group By' attributes. In the case of a unique attribute like 'Time' (eventReceiveTime)

each event would form its own group.

2. FortiSIEM 7.2.0 Concepts Guide

Page 10

"Event Attributes". This section details the attributes used to describe events. Attributes like user

srcIpAddr

and eventReceiveTime are fundamental. The uniqueness of eventReceiveTime for each distinct event log is a core concept

which supports the reasoning that if 'Time' were used in the grouping

each of the six events would constitute a separate result.

FortiSIEM employs a hierarchical and flexible thresholding system for performance metrics. It provides a set of system-defined global thresholds that serve as a baseline for all monitored devices. For environments requiring more specific monitoring, administrators can configure per-device thresholds. When a per-device threshold is set for a specific metric, it takes precedence over and overrides the corresponding global threshold for that device only. This dual approach allows for both broad, generalized monitoring and granular, device-specific tuning.

A. Thresholds are not fixed or hardcoded; they are fully configurable by administrators at both the global and per-device levels to suit specific environmental needs.

B. FortiSIEM uses thresholds primarily for performance and availability metrics, not just security metrics, and it utilizes both global and device-level settings.

D. FortiSIEM does not rely solely on global thresholds. The ability to set per-device thresholds is a key feature for accurate and customized performance monitoring.

1. FortiSIEM 7.0.0 Administration Guide

Page 319

Section: "Setting Performance Monitoring Thresholds".

The document states

"FortiSIEM has a set of built-in system-defined performance monitoring rules that use global thresholds for monitored metrics... You can also define thresholds for specific devices

which will override the global thresholds." This directly confirms the use of both global and per-device thresholds for performance metrics.

2. FortiSIEM 7.0.0 Concepts Guide

Page 11

Section: "Performance and Availability Monitoring".

This guide explains

"FortiSIEM can monitor a wide variety of performance and availability metrics... and generate an event when a metric crosses a user-defined threshold." This confirms that thresholds are user-configurable

refuting the "fixed

hardcoded" claim in option A.

The rule fails to generate incidents because of a mismatch between the event type being filtered and the attributes used in the Group By clause. The filter condition selects events with Event Type = 'fsm-cmdb-event-attr-change'. This is an internal FortiSIEM event that signals a change to a CMDB device attribute. Such events typically do not contain network traffic attributes like Source IP and Destination IP.

The rule's aggregation is grouped by Reporting IP, Source IP, and Destination IP. For an event to be included in the aggregation count, it must contain all the attributes specified in the Group By clause. Since the matched CMDB change events lack these specific IP address attributes, they are discarded before the aggregation step. Consequently, the count never reaches the threshold of 1, and no incident is triggered.

A. The Event Type fsm-cmdb-event-attr-change is a valid internal event type, not a CMDB lookup. The issue is the incompatibility of this event's attributes with the rest of the rule logic.

B. The CONTAINS operator does not require a fully qualified domain name. It correctly matches any event where the Destination Host Name field includes the substring 'bad.domain.com'.

D. The aggregate condition COUNT(Matched Events) >= 1 is the least restrictive setting possible. It is designed to trigger on the very first qualifying event, so it is not too restrictive.

1. FortiSIEM 7.1 - Administration Guide

Page 338

"Defining Rule Conditions":

The documentation explains the rule structure: "A rule has three parts: Filter

Aggregation

and Trigger." It further details the Group By clause: "The aggregation function is applied to events that have the same values for the attributes in the Group By list." This implies that if an event does not have the specified Group By attributes

it cannot be grouped and is therefore excluded from the aggregation calculation.

2. FortiSIEM 7.1 - Event Attributes and Types

Page 10

"FortiSIEM Generated Events":

This document lists fsm-cmdb-event-attr-change as a FortiSIEM system-generated event. The attributes associated with such events relate to CMDB object details (e.g.

cmdbDevName

cmdbChangedAttr

cmdbNewAttrVal) and not typically network flow information like Source IP or Destination IP

which are required by the rule's Group By clause. This confirms the attribute mismatch.

The = operator in the FortiSIEM search filter performs an exact match. This means the search is looking for events where the entire Raw Event Log field is exactly equal to the string "udp". A raw syslog message from a FortiGate contains extensive information (timestamps, IP addresses, action, etc.), and will never consist solely of "udp". To find a keyword within the raw log, the correct operator is CONTAINS, which searches for the specified substring anywhere in the field's value.

A. The AND operator is irrelevant as there is only one filter condition. It is used to combine multiple conditions, which is not the case here.

B. The analyst's goal is to search the "last two hours". The selected time range is correct. Setting it to Real-Time would only show new, incoming events, not historical ones.

C. While searches can be case-sensitive, the fundamental issue is the operator. Using = would fail to find results even if the case was correct (UDP) because the entire log is not just that word.

1. FortiSIEM 7.2.0 - Analytics Guide

Page 101

"Defining Filter Conditions".

The guide describes the available operators for building search queries. It defines the = (is equal to) operator as: "Matches if the attribute value is exactly equal to the specified value."

It defines the CONTAINS operator as: "Matches if the attribute value contains the specified value." This documentation directly supports that = is the wrong operator for a keyword search within a larger text field like Raw Event Log.

The exhibit displays the configuration settings for a local user within FortiSIEM. The "Group" field is used to assign the user to a specific group defined within the FortiSIEM Configuration Management Database (CMDB). The CMDB is a core component of FortiSIEM that stores information about all monitored entities, including devices, users, and user groups. These CMDB groups are used for organizing users and can be leveraged in rules, reports, and incident definitions. The "Authentication: Local" setting confirms the user is managed internally by FortiSIEM, not by an external directory service.

A. FortiSIEM organization group: An "Organization" in FortiSIEM is a top-level construct for multi-tenancy, not a group for individual users.

B. LDAP user group: This would be applicable only if the user's authentication method was set to LDAP, not "Local" as shown.

D. Windows Active Directory user group: This would be relevant only if authentication was configured for Active Directory, which is not the case for a local user.

1. FortiSIEM 7.2.0 Administration Guide

Page 101

"Users" section.

The guide details the process of creating a user under the "Admin" tab. It specifies that the "Group" drop-down list contains CMDB user groups

stating: "Select the CMDB group to which this user belongs." This directly confirms that the group is a CMDB entity.

2. FortiSIEM 7.2.0 CMDB and Discovery Guide

Page 10

"CMDB Objects" section.

This document outlines the structure of the CMDB

which includes various object types. "User Groups" are listed as a manageable CMDB object type

reinforcing that user grouping is a function of the CMDB.

When a FortiSIEM rule triggers, it generates an incident with a unique key based on the rule name, incident source, and incident target. If the same rule triggers again with the identical key attributes, FortiSIEM does not create a new, separate incident. Instead, it performs incident aggregation by updating the existing incident record. Specifically, it increments the Incident Count value and updates the Last Seen timestamp to reflect the most recent occurrence. This mechanism prevents incident flooding and consolidates recurring events into a single, manageable entry.

A. FortiSIEM does not use a "Repeated" status for incident aggregation; it uses the Incident Count field to track the number of occurrences.

C. The "Rule Frequency" setting determines how often a rule is evaluated, not how it handles repeated triggers by generating new incidents.

D. Generating a new incident for each trigger is inefficient and would clutter the incident dashboard. FortiSIEM's aggregation logic is designed to prevent this.

---

1. FortiSIEM 7.0.0 Concepts Guide

Chapter: Incidents

Section: Incident Aggregation.

"When a rule triggers

FortiSIEM checks if an incident with the same rule name

incident source

and incident target already exists. If it does

then FortiSIEM increments the incident count and updates the last seen time of the existing incident. If it does not

then FortiSIEM creates a new incident."

2. FortiSIEM 7.0.0 Administration Guide

Chapter: Using the Analytics View

Section: Viewing Incidents.

This section describes the incident table columns

including Incident Count ("Number of times the incident has occurred") and Last Seen ("Time the incident last occurred")

which are the two fields updated during aggregation.

FortiSIEM’s built-in device pack for FortiClient EMS uses the EMS REST API (GET /api/v1/EMS/client) to pull a limited endpoint inventory: host identifiers, OS and FortiClient versions, logged-on user, security posture, EMS tags and ZTNA tags. The API response explicitly contains the field ztnaTags, which FortiSIEM stores and can use in correlation rules. The API does not deliver the complete list of installed host software, any license information for FortiSIEM itself, or user passwords/credentials—only the username string. Therefore, among the choices, only ZTNA tags are retrievable.

A. Host software versions – API returns only OS/FortiClient version, not the full “host software versions” inventory implied here.

B. FortiSIEM license – EMS API has no field related to FortiSIEM licensing.

C. Host login credentials – Only the current username is returned; passwords/credentials are never exposed.

1. Fortinet

“FortiSIEM External Systems Configuration Guide 7.0.0”

Section “FortiClient EMS (API)”

pp. 297-298: lists endpoint fields hostName

osVersion

clientVersion

tags

ztnaTags.

2. Fortinet

“FortiClient EMS REST API Reference 7.0.1”

§ 3.4 “GET /api/v1/EMS/client”

Table 3-2: response object includes ztnaTags

no software inventory or credential fields.

3. Fortinet

“FortiSIEM Administration Guide 7.1.0”

Appendix A “Supported Device Types”

entry “FortiClient EMS”: shows collected attributes include ZTNA tags and excludes license or credential data.

In FortiSIEM, the attributes that can be used to construct an incident title are determined by the rule's configuration. Specifically, the "Available Attributes" list shown in the incident definition step is populated from the attributes selected in the "Triggered Attributes" section of the rule's pattern definition. If an attribute like "Destination Host Name" is not available for the title, it means it was not selected to be carried over when the rule's conditions were met. Therefore, the analyst must edit the rule and add "Destination Host Name" to the "Triggered Attributes" list.

B. Setting an attribute as an aggregate item is for grouping related events within a rule, not for making it available in the incident title.

C. "Destination Host Name" is an event attribute (a piece of data within an event), not an event type (a classification of the event itself).

D. Removing one attribute has no effect on the availability of another; attributes are made available by explicitly adding them, not by removing others.

1. FortiSIEM 7.2.0 User Guide

Page 338

Chapter: Analytics > Rules > Creating a New Rule > Step 3: Define Incident.

The guide states: "The Incident Title can be customized by dragging and dropping attributes from the Available Attributes list. The attributes in this list are defined in the Triggered Attributes section of the rule definition." This directly confirms that the source of available attributes for the title is the "Triggered Attributes" list.

2. FortiSIEM 7.2.0 Concepts Guide

Page 110

Chapter: Rules > Rule Definition.

This section explains the components of a rule

including the "Trigger" section. It clarifies that the attributes selected here become part of the triggered event

which is then used to create the incident. This establishes the link between selecting an attribute in the rule's logic and its availability for the incident.

A FortiSIEM automation policy defines the set of actions to be taken when an associated rule is triggered. The configuration interface, as shown in the exhibit, allows an administrator to select multiple actions simultaneously using checkboxes. When the policy is invoked, FortiSIEM executes all the actions that have been selected. In this case, it will send an email, run the remediation script, send an SNMP trap, and send a syslog message. There is no precedence or ordering that limits the execution to a single action.

A. Remediation scripts do not have inherent precedence over other actions. All selected actions are executed when the policy is triggered.

C. The integration policy is a separate, selectable action, not a fallback mechanism. It is also not selected in the exhibit's configuration.

D. The position of an action in the user interface list does not determine execution priority. All checked actions are performed.

1. Fortinet

FortiSIEM 7.2.0 Administration Guide

Page 301

"Defining an Automation Policy". The guide states

"Select one or more of the following actions to take when a rule triggers

" explicitly indicating that multiple actions can be chosen and will be executed. The subsequent descriptions for each action type do not mention any priority system.