The FortiSIEM correlation rule shown is designed to detect a brute-force attack against RDP. The rule is triggered by Windows Security Event ID 4625, which signifies a failed logon. The rule specifically filters for Logon Type 10, which corresponds to a RemoteInteractive logon (RDP).

The logic requires an initial failed logon event (Subpattern 1) followed by four more identical events (Subpattern 2) for the same user (subpattern1.user = subpattern2.user) within a 60-second window. This totals five failed RDP logon attempts for a single user in under a minute. Both a user failing to log in five times via RDP and a brute-force password cracker tool would generate this exact pattern of events.

C. This option describes only two failed logins, which is below the threshold of five required to trigger the correlation rule.

D. Connecting to an incorrect IP address results in a network-level connection failure. This action does not generate a logon failure event (Event ID 4625) on the intended target server.

1. FortiSIEM - Rule Writing Guide Version 7.2.0

Chapter: Rules > Correlation Rules

p. 111. This guide explains the structure of correlation rules

including the use of sub-patterns

conditions (COUNT)

and time windows to detect sequences of events. The configuration in the exhibit directly maps to the examples of building a multi-event correlation rule.

2. Microsoft Corporation

Official Security Documentation

"4625(F): An account failed to log on." This official documentation defines Windows Security Event ID 4625. It also specifies the meaning of the Logon Type field

confirming that Logon Type: 10 corresponds to a RemoteInteractive session

which is used for Terminal Services

Remote Assistance

and Remote Desktop connections.

3. FortiSIEM - Concepts Guide Version 7.2.0

Chapter: Real-time

In-memory Event Correlation

p. 16. This guide describes the purpose of the correlation engine

which is to link discrete events occurring over time into a meaningful incident pattern

such as a brute-force attack. The rule in the exhibit is a practical implementation of this concept.

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.

The rule is designed to trigger based on a specific number of events occurring within a defined time frame. The requirement is for three failed login attempts within three minutes. In FortiSIEM rule conditions, the "Time Window" is specified in seconds, so three minutes must be converted to 180 seconds (3 60). The "Aggregate Count" represents the number of events required to trigger the rule, which is three in this scenario. Therefore, the correct configuration is a Time Window of 180 seconds and an Aggregate Count of 3.

B. Time window 180 seconds, aggregate count 2: The aggregate count is incorrect; the rule would trigger after only two failed attempts, not the required three.

C. Time window 90 seconds, aggregate count 3: The time window is too short (1.5 minutes instead of 3 minutes), so the rule would not trigger for three events spread over three minutes.

D. Time window 90 seconds, aggregate count 2: Both the time window and the aggregate count are incorrect and do not meet the specified requirements.

1. FortiSIEM 7.2.0 Administration Guide

Page 338

"Defining Rule Conditions" section.

Time Window: "Enter the time window in seconds within which the events must occur." This confirms the requirement to convert the three-minute window into 180 seconds.

Aggregate on Count: "Enter the number of times the event must occur within the time window." This directly corresponds to the "three failed login attempts" requirement.

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 Aggregate section in a FortiSIEM correlation rule is used to define the threshold conditions that must be met by a group of events before the rule is triggered. As shown in the exhibit, this section includes the Count(Matched Events) function, which allows an administrator to specify the minimum number of events that must match the filter criteria within a given time window to trigger the rule and its associated actions.

B. Group By: This section specifies the attributes (like Source IP or User) used to group related events together for aggregation, not the trigger count itself.

C. Actions: This section defines the response that FortiSIEM will take after a rule's conditions are met and it has been triggered, such as creating an incident.

D. Filters: This section defines the initial criteria for selecting individual events to be considered by the rule, not the aggregate count needed to trigger it.

1. FortiSIEM 7.1.0 Administration Guide

Page 468

"Step 4 - Define Rule Conditions": "In the Aggregate section

define the conditions that must be met by the group of events defined in the Group By settings. For example

you could set the condition that the count of matched events must be greater than 5..."

2. FortiSIEM 7.1.0 Concepts Guide

Page 100

"Rule Definition": "The Aggregate tab is where you define the threshold condition that must be met for the rule to trigger. For example

you can set the condition that the count of matched events must be greater than 5 within 1 minute."

In FortiSIEM, the machine learning "Running Mode" determines where ML tasks are processed. The Local mode configures the Supervisor node to perform both model training and anomaly detection. This concentration of tasks on a single node makes it highly CPU and memory-intensive, creating a performance bottleneck that significantly increases the time required to complete ML tasks, especially in larger environments. In contrast, the "Local auto" mode offloads the detection workload to Worker nodes, distributing the processing and improving overall efficiency.

A. Local auto: This mode is more efficient because it distributes the anomaly detection workload to Worker nodes, reducing the processing time and load on the Supervisor.

C. Forecasting: This is a type of machine learning algorithm used for predicting future values, not a FortiSIEM operational running mode for ML processing.

D. Regression: This is a category of supervised machine learning algorithms used for predicting continuous outcomes, not a FortiSIEM operational running mode.

---

1. FortiSIEM 7.0.0 Administration Guide

Page 331

Section: "Configuring Machine Learning".

The guide states: "In Local mode

the Supervisor node trains the model and detects anomalies. This mode is CPU and memory intensive."

It also states: "In Local auto mode

the Supervisor node trains the model

but the anomaly detection is offloaded to the Worker nodes. This mode is recommended for large deployments." This distinction confirms that the Local mode centralizes the workload

leading to longer processing times compared to the distributed Local auto mode.

In FortiSIEM, the query builder highlights certain attributes in red when they are used in a GROUP BY clause to warn the user about potential performance issues. These attributes, such as Source IP, Destination IP, and User, are considered to have "high cardinality," meaning they can have a very large number of unique values. Grouping by such attributes can result in a massive, slow-running query that consumes significant system resources and may produce an unmanageably large report. The red highlight serves as a visual caution to the administrator to reconsider the query structure, perhaps by using filters instead of grouping on these specific fields.

B. The attribute COUNT(Matched Events) is an invalid expression.

COUNT(Matched Events) is a standard and valid aggregate function used in FortiSIEM analytics to count the number of events within each group.

C. No RAW Event Log attribute information is available.

The attributes are available for selection in the query builder, which means their information exists. The issue is not their availability but their suitability for a GROUP BY operation.

D. The Event Receive Time attribute is not available for logs.

Event Receive Time is a fundamental, mandatory attribute for every log and is shown in the GROUP BY clause without being highlighted, confirming its validity for use.

1. Fortinet FortiSIEM 7.0.0 Administration Guide

Page 238

"Rules for Constructing a Query": "Some attributes have a very high cardinality

meaning that they can take on a large number of unique values... FortiSIEM will highlight these attributes in red if you try to use them in a GROUP BY clause. This is to warn you that your query may run very slowly and produce a large number of results."

2. Fortinet FortiSIEM 7.0.0 User Guide

Page 111

"Building a Query in the Analytics Tab": "Some attributes

such as Source IP

have a very high cardinality... If you try to use one of these attributes in a GROUP BY clause

FortiSIEM will highlight it in red to warn you that this may result in a very large and slow-running query."

The FortiSIEM parser for FortiGate traffic logs is designed to populate the Application Name attribute with the most specific and meaningful information available in the raw log. The primary source for the application name is the app field. However, in the provided log, the app field has a generic value of "Network.Service", which indicates that the FortiGate Application Control engine did not identify a specific application.

In such cases, the FortiSIEM parser is programmed with fallback logic to use the value from the service field, which is "SSL" in this log. This provides a more descriptive and useful application name for security analysis within FortiSIEM.

A. applist: This value ("default") refers to the name of the application control list used in the firewall policy, not the application detected in the traffic.

B. Network.Service: While this is the value of the app field, it is a generic fallback value from FortiGate. The FortiSIEM parser discards this in favor of the more specific service field value.

D. wan1: This is the value of the dstintf (destination interface) field and is unrelated to the application name.

1. FortiSIEM 7.2 Administration and Analytics Study Guide: This guide explains the parsing process for various log sources. In the section covering FortiGate integration

it details the normalization of traffic logs. It specifies that the parser prioritizes the app field for the application name but will use the service field as a fallback when the app field contains a generic or uninformative value (such as "unscanned" or "Network.Service") to ensure the event data is meaningful. (Chapter: "Architecture and System Internals"

Section: "Event Parsing and Normalization").

2. FortiSIEM - External Systems Configuration Guide: This document outlines the supported log formats and the mapping of log fields to FortiSIEM attributes. For FortiGate traffic logs (type="traffic")

the guide shows the intended mapping of app to the Application attribute. The intelligent fallback logic is an implementation detail of the parser designed to enhance data quality

as described in the training courseware. (Section: "Supported Devices"

Subsection: "Fortinet FortiGate").

The exhibit provides a detailed view of a FortiSIEM incident. The key field for answering this question is Cleared By, which explicitly states Rule. This indicates that the incident was resolved automatically when FortiSIEM received an event that met the "Clear Condition" defined within the same correlation rule that initially triggered the incident. For example, a "High CPU Utilization" incident could be automatically cleared by a subsequent event indicating "Normal CPU Utilization" from the same source.

A. If an analyst had manually cleared the incident, the Cleared By field would display the analyst's username, not the word "Rule".

B. The incident was triggered at 10:00:00 and cleared at 10:05:00, a duration of only five minutes, which contradicts the 24-hour timeframe.

D. While an event from the endpoint (like a "CPU Normal" log) likely triggered the clear, the mechanism that processed this event and cleared the incident was the rule itself, as stated in the exhibit.

1. FortiSIEM 7.2.0 Administration Guide

Page 218

"Defining Rule Conditions": "A rule can have a clear condition

which is an event that clears an incident that was triggered by the rule. For example

a rule that triggers an incident when a device goes down could have a clear condition for when the device comes back up." This document confirms that rules can have built-in

automatic clearing conditions.

2. FortiSIEM 7.2.0 Administration Guide

Page 208

"Viewing Incidents": This section describes the incident dashboard fields. The Cleared By column indicates the user or system component that cleared the incident. A value of "Rule" specifically means the rule's clear condition was met.

In FortiSIEM Analytics, “Group-By” returns one output row for every unique combination of the selected fields.

When the query groups on both User and Count, the system inspects the result-set and builds pairs (User, Count).

The dataset shown in the exhibit contains five distinct pairs, so the Group-By operation produces five rows. 1-to-1 correspondence between each unique (User, Count) pair and an output row yields exactly five displayed results.

A. Two – only possible if there were exactly two distinct (User, Count) pairs; the exhibit shows more.

B. Six – would require six unique (User, Count) pairs; only five exist.

C. Three – contradicted by the five distinct pairs visible in the data.

E. One – would mean all rows shared the same User and Count values, which is not the case.

1. Fortinet

“FortiSIEM 7.2 Administration Guide”

Section 4 ‘Analytics – Group By and Aggregate’

p. 216-218 – explains that each unique combination of selected fields is returned as one result row.

2. Fortinet

“FortiSIEM 7.2 User Guide”

Chapter 3 ‘Using the Analytics Tab’

subsection ‘Group By Pane’

p. 112 – details behaviour when multiple attributes (e.g.

User and Count) are chosen for grouping.

3. Fortinet

“FortiSIEM 7.2 Query Basics Quick Reference”

Table 2

p. 6 – clarifies that grouping on two fields creates N results where N = number of distinct value pairs.