DO NOT REPRINT

© FORTINET

Advanced Analytics
Study Guide
for FortiSIEM 6.3
DO NOT REPRINT
© FORTINET
Fortinet Training

https://training.fortinet.com

Fortinet Document Library

https://docs.fortinet.com

Fortinet Knowledge Base

https://kb.fortinet.com

Fortinet Fuse User Community

https://fusecommunity.fortinet.com/home

Fortinet Forums

https://forum.fortinet.com

Fortinet Support

https://support.fortinet.com

FortiGuard Labs

https://www.fortiguard.com

Fortinet Network Security Expert Program (NSE)

https://training.fortinet.com/local/staticpage/view.php?page=certifications

Fortinet | Pearson VUE

https://home.pearsonvue.com/fortinet

Feedback

Email: courseware@fortinet.com

9/15/2021
DO NOT REPRINT
© FORTINET

TABLE OF CONTENTS

01 Introduction to Multi-Tenancy 4
02 Defining FortiSOAR, Collectors, and Agents 42
03 Operating Collectors 69
04 Windows and Linux Agents 120
05 Rules 169
06 Single Subpattern Security Rules 197
07 Multiple Subpattern Rules 238
08 Baselines 262
09 Baseline Rules 319
10 FortiSIEM UEBA 353
11 MITRE ATT&CK® 385
12 Clear Conditions 414
13 Remediation 439
 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about deploying FortiSIEM in a multi-tenant environment, and identify key
implementation requirements. You will also learn about deploying FortiSIEM with and without collectors, and
how FortiSIEM collect logs without a collector.

Advanced Analytics 6.3 Study Guide 4

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in multi-tenancy, you will be able to determine a customer deployment model,
and deploy FortiSIEM with and without a collector.

Advanced Analytics 6.3 Study Guide 5

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this section, you will learn about FortiSIEM multi-tenancy and how you can manage customer scopes on
FortiSIEM.

Advanced Analytics 6.3 Study Guide 6

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Businesses worldwide are struggling to secure their networks against determined attackers who are
commonly two steps ahead of the defenders. There is a perfect storm of challenges facing organizations
wanting to expand into the new digital market, without compromising their security or brand.

Studies show that not only is the number of network attacks increasing, but that the cost of being breached
has also continued to rise with each incident. Media attention on high-profile security breaches has also
created a higher level of awareness among business leaders, about the risks and costs of security breaches
to businesses. The depth and breadth of criminal and state-sponsored cybercriminals, who are often well
funded and are developing increasingly sophisticated attacks, is better understood by security buyers today
than ever before, and at the same time, the security skills shortage continues to widen.

As a result, many CISOs are looking to migrate some or all of their risk out of their IT departments and into the
hands of professionals such as managed security service providers (MSSPs).These MSSPs are expected to
anticipate and secure networks against innovative and determined threat actors.

Advanced Analytics 6.3 Study Guide 7

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

At its core, an MSSP must provide two kinds of basic services: security device management and continuous
monitoring. Customers with multiple locations and business-critical applications running across the network
have stringent uptime requirements; so, device management and monitoring are crucial to maintain business
productivity.

Many service providers also add security analytics and threat intelligence services to help mitigate new
attacks, including actionable intelligence and a comprehensive view of the distributed security infrastructure.
Going forward, these firms will likely differentiate themselves in new areas such as security analytics, threat
intelligence, information portals, and customer service.

Many MSSPs will also want to provide security remediation, incident response, compliance services, or loss
prevention, to further differentiate their organization in the market. Securing thousands of customer locations,
meeting service-level agreements (SLAs), and balancing profitability with engineering headcount and
infrastructure are ongoing challenges facing MSSPs. So MSSPs need specialized security vendors that
understand their business model and can help them meet customer requirements.

Advanced Analytics 6.3 Study Guide 8

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

A key requirement for MSSPs with a large, distributed customer base is support for multi-tenancy, or the
ability to support multiple customers from a single centralized management console. FortiSIEM is a highly
customizable, multi-tenant architecture that enables MSSPs to manage a large number of physical domains,
logical domains, and overlapping systems and networks, from a single console. In this environment, it is very
easy to cross-correlate information across physical and logical domains and individual customer networks.
Not only is FortiSIEM natively multi-tenant, it is also built for the cloud. It is easy to install and manage either
as a virtual machine (VM) in an MSSP or customer data center, or as an instance in an Amazon Web
Services (AWS) or Microsoft Azure environment. FortiSIEM can even be run as a hybrid model, and is the
only product with the ability to seamlessly move from cloud to premises and from premises to cloud.

Compartmentalizing SIEM operations can be done in a variety of ways. Just as administrative domains
(ADOMs) can be broken into sections based on customer, location, and so on, FortiSIEM can be divided into
what are known as organizations. This allows the MSSP to overlay an aggregate view of all tenants, that
allows data and events to be managed based on business requirements.

Advanced Analytics 6.3 Study Guide 9

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In the enterprise mode of FortiSIEM, there is just one organization, called the super organization. In a service
provider deployment, FortiSIEM supports multi-tenancy through multiple organizations, alongside the super
organization.

Advanced Analytics 6.3 Study Guide 10

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In addition to the service provider defining new organizations, FortiSIEM creates two organizations by default,
for ease of management. The super local and super global organizations are built in, and are not shown under
the Organizations tab.

Advanced Analytics 6.3 Study Guide 11

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

The super local organization, also known simply as super, can be thought of as the FortiSIEM back end, or a
local tenant. Service providers can discover and monitor their own devices under this organization just like the
enterprise edition. By default, everything belongs to the super organization, unless other customers are
added.

Advanced Analytics 6.3 Study Guide 12

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Super global is a virtual organization that can view all organizations under management, including the super
organization. Users belonging to the super global organization can see other organizations and their data.

After installation, FortiSIEM automatically creates an administrator user with full administrator rights for the
super global and super local organizations. When the user creates a new organization, FortiSIEM creates an
administrator user for that organization. These are accounts with full administrator rights. FortiSIEM users with
full administrator rights can create roles and then create users and assign them a role.

You can configure roles on FortiSIEM to restrict what users can see and do. You can restrict GUI visibility,
organization visibility, and data by writing filters on device type, event type, and any parsed event attribute.

Advanced Analytics 6.3 Study Guide 13

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Scopes on FortiSIEM are administrative views where logs sent by a collector from a customer location can be
viewed locally. Therefore, the scope is sometimes called local for an individual customer. Users belonging to
local organizations and user-defined organizations can see only their own organization.

Advanced Analytics 6.3 Study Guide 14

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Service provider administrator users can change scopes for administration purposes. This allows the
administrator to change the organization view.

Advanced Analytics 6.3 Study Guide 15

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

You can log in to the supervisor node as a super global user, if you are a service provider administrator. To
log in to the supervisor node as a super global user, in the CUST/ORG ID field, type super. You can also log
in to the individual organization by typing the organization name in the CUST/ORG ID field.

Advanced Analytics 6.3 Study Guide 16

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

If you are the administrator for a customer, you can access your organization view by logging in to the default
login screen with an administrator account that was set up for your organization.

Advanced Analytics 6.3 Study Guide 17

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this section, you will learn about various common deployment modes for FortiSIEM in a multi-tenant
environment.

Advanced Analytics 6.3 Study Guide 18

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Service providers can deploy FortiSIEM without a collector, which is best suited for a hosting type
environment. The key is that each customer is on a unique IP address scheme, with no overlap allowed.
Typically, each customer device is local to the FortiSIEM cluster, and you can distinguish events and incidents
by filtering with the reporting IP address of devices that belong to individual customers.

Advanced Analytics 6.3 Study Guide 19

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

A service provider with a collector is the most common deployment type for service providers or very large
enterprises using multi-tenancy features. This deployment model allows for overlapping IP address ranges.
Each customer can have one or more collectors defined. Collectors can be placed anywhere on the LAN,
WAN, DMZ, or remote sites across the internet or in the cloud. Additional benefits, such as remote
administration of customer devices, is possible if collectors are used.

Advanced Analytics 6.3 Study Guide 20

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

You can also deploy FortiSIEM in a hybrid manner. In hybrid deployments, some customers will have
collectors, which are responsible for collecting and sending logs to the FortiSIEM cluster, while other
customers can send logs directly to the FortiSIEM cluster. The rules of an overlapping IP address schema still
apply in a deployment without a collector. Customers who do not have collectors will need to be on a distinct
IP subnet.

Advanced Analytics 6.3 Study Guide 21

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this section, you will learn about adding customers on FortiSIEM, and defining collectors for those
customers. You will also learn about adding an IP range for customers without collectors.

Advanced Analytics 6.3 Study Guide 22

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

When you create a new organization, the organization name is the name of the new customer, which will be
referenced on the GUI. Typing a value in the Full Name field is optional, and what you type here is not
displayed elsewhere. The values that you type in the Admin User and Admin Password fields define the
local administrator account username and password for this customer. The value that you type in the Admin
Email filed is the email address that will be set for the administrator user for that customer, which is
particularly useful for sending alerts and incidents to the administrator user for that organization. Each new
organization is automatically given an organization ID, which will be enriched in every new event collected or
received for that organization.

Advanced Analytics 6.3 Study Guide 23

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Organizations can be defined in one of two ways. You can associate one or more collectors with an
organization. The devices monitored by the collector or the events sent to the collector, automatically belong
to the associated organization. You can also define an IP range for an organization. If the sending IP of a
device belongs in the IP range, then the device and logs belong to that organization.

Advanced Analytics 6.3 Study Guide 24

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

The maximum number of monitored configuration management database (CMDB) devices for the
organization can be defined in the Max Devices field. This value is reserved from the overall system device
license. The max device feature is applicable only to organizations with collectors.

Advanced Analytics 6.3 Study Guide 25

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

There is a limit to the maximum number of devices that you can assign to an organization, and that limit
depends on the license that was purchased from Fortinet. You cannot exceed the total devices limit for the
whole system.

Advanced Analytics 6.3 Study Guide 26

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Various fields, including the organization name, can be edited after definition. However, fields such as Admin
Password, cannot be changed.

Advanced Analytics 6.3 Study Guide 27

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this section, you will learn about discovering devices and collecting events for customers without collectors.

Advanced Analytics 6.3 Study Guide 28

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

Organizations without collectors are defined by unique IP addresses, which can be a single IP address,
multiple comma separated IP addresses, or an IP address range. Note that classes inter-domain routing
(CIDR) notation is not supported here. If you have multiple networks defined on a device like a router, then
you need to define the subnet or IP range for each interface on FortiSIEM. All interface IP addresses count
during discovery, unless an exclusion is defined.

Advanced Analytics 6.3 Study Guide 29

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

You can add credentials for organizations without collectors on the Credentials tab. You will need to be
logged in as a super global user. It is a best practice to name credentials in an organized manner, so that you
can identify the credentials for each organization.

Advanced Analytics 6.3 Study Guide 30

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

You can define discovery definitions for deployment without collectors on the Discovery tab. You will have to
log in as a super global user. Since multiple discovery entries will be defined under the same view, you should
develop a good naming scheme.

Advanced Analytics 6.3 Study Guide 31

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

The supervisor node performs all discovery, if there are no defined collectors. The supervisor will
automatically discover devices, applications, and users in the customer’s IT infrastructure and starts
monitoring them.

Any discoveries that do not match an organization IP range belong to the super organization.

Advanced Analytics 6.3 Study Guide 32

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

To scale a deployment without collectors, you need to add a load balancer so that logs can be balanced in an
orderly way, and distributed across all workers and the supervisor, without choking the performance of any
single node in the cluster. Remember that not all protocols are supported when you introduce a load balancer
to the environment. Syslog and SNMP traps from the network and servers are fine, but protocols such as WMI
for performance monitoring, or Windows event log collection, are actually polls from FortiSIEM itself, so those
requests cannot be load balanced, and needs to go directly to the device that is being polled.

To identify the customer data, the receiving node in a FortiSIEM cluster without a collector looks up which
customer the reporting IP belongs to, and tags the event with the customer name and customer ID. This way,
you can filter events using the customer ID or name to perform analytics. If an incident is generated for a
customer, you can identify the customer by looking at the events that generated the incident.

Any undefined reporting IP addresses belong to the super organization, and will be tagged as a local asset of
the service provider.

Advanced Analytics 6.3 Study Guide 33

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

As the customer base grows and more devices are added to the customer infrastructure, the number of
events per second (EPS) also increases. As the EPS increases, the resources on the FortiSIEM cluster can
be under strain. More workers need to be added to the FortiSIEM cluster to balance the load.

Advanced Analytics 6.3 Study Guide 34

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In this section, you will learn about multi-tenancy architecture on FortiSOAR.

Advanced Analytics 6.3 Study Guide 35

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

When you escalate an alert on FortiSOAR, it becomes an incident. Every incident on FortiSOAR can be
considered as a ticket that an analyst will need to work on until they close the incident.

The FortiSOAR queue management feature provides you with an overview of the work (records) that must be
completed and enables you to assign pending work to users. You can also reassign assignments in case of
absence or analyst shift changes.

Administrators can create applicable dashboards throughout the application. The dashboards are assigned to
users based on their roles. For example, you can create a dashboard that displays alerts that are critical and
high, and then assign them to users who have the role of handling alerts. Users can prioritize their work by
looking at their dashboard, which displays critical and high alerts.

FortiSOAR gives you the option to assign levels of accessibility to users using role-based access control
(RBAC) combined with team membership. You can grant users access to specific modules in FortiSOAR
based on their role permissions. Users exercise their permissions in conjunction with their team
membership(s).

Advanced Analytics 6.3 Study Guide 36

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In an enterprise architecture, there is one single instance of FortiSOAR. You can ingest data using connectors
into FortiSOAR from various devices in your infrastructure. When available, it is recommended that most logs
be sent through the SIEM, rather than through direct connectors. This ensures the SIEM is a central point of
log aggregation and can be used for analytics and reporting.

After you integrate your FortiSIEM, or any other SIEM solution, with FortiSOAR, incidents generated by
FortiSIEM are ingested by FortiSOAR. Every incident that is sent from FortiSIEM to FortiSOAR is a unique
record on FortiSOAR. You can run remediation playbooks from FortiSOAR against those incidents, and
perform remediation action on the target devices. For example, if the logs that are sent by FortiGate to
FortiSIEM generate an incident that indicates an external malicious actor is trying to access corporate
resources, then FortiSOAR evaluates that incident and rates that external IP against various threat
intelligence platforms. If the IP is malicious, then you can run a remediation playbook to take action against
that IP address. In the scenario shown on this slide, the solution is to block that IP on the FortiGate firewall.
The playbook can automatically log in to FortiGate and put that IP on the quarantine list for an indefinite period
of time.

Advanced Analytics 6.3 Study Guide 37

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In the case of shared tenancy, tenants share the same system as the primary device; that is, tenants are
local, but with restricted access on the system. The SOC team provides cybersecurity monitoring and
management to various tenants in a single FortiSOAR instance. The shared tenancy model ensures that the
data belonging to different tenants is segregated, and data access is controlled using RBAC. Therefore, a
tenant can view only their own data or record, and not the data of other tenants.

You can give each tenant their own login, which they can use to view their dashboards, report, check the
actions taken on their records, check their SLA management, and so on.

Advanced Analytics 6.3 Study Guide 38

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In the case of a distributed tenancy model, the tenant node instance of FortiSOAR is remote and every tenant
has their own instance of FortiSOAR. The primary FortiSOAR node resides at the MSSP location and
communicates with the tenant node through a secure channel. Tenant data remains in the tenant
environment, and they control how much data they want to share with the primary node. All sensitive
information stays with the tenant node. Since the actual workflow execution happens at the tenant node itself,
the primary node requires only the summary of information to help identify what investigations should run. The
primary node pushes any action that needs to be executed to the tenant node. Similarly, any playbook that
needs to be executed is pushed by the primary node to the tenant node.

Advanced Analytics 6.3 Study Guide 39

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

In a multi-tenant hybrid model, the primary node centrally manages some customers. If the customer is
managed by the primary node, then there is no requirement for a tenant node for that customer. Then there
are other customers who use a distributed method. For those customers, you must install a tenant node.

Advanced Analytics 6.3 Study Guide 40

 Introduction to Multi Tenancy

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to deploy FortiSIEM in a multi-tenant
environment and identify key implementation requirements. You also learned about deploying FortiSIEM with
and without collectors, and how FortiSIEM collect logs without a collector.

Advanced Analytics 6.3 Study Guide 41

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about defining and deploying collectors. You will also learn about collector
operation, and scaling collectors as organizations grow. Additionally, you will learn to ingest data into
FortiSOAR from FortiSIEM.

Advanced Analytics 6.3 Study Guide 42

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding collector architecture, you will be able to configure collector
buffer sizes, define upload definitions for logs, and establish communication with supervisor nodes and
collector nodes.

Advanced Analytics 6.3 Study Guide 43

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about collector architecture and various processes involved in collector
architecture.

Advanced Analytics 6.3 Study Guide 44

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

A collector enables FortiSIEM to collect logs and performance metrics from geographically disparate
networks. Data collection protocols, such as SNMP and WMI, are often chatty, and the devices may be
reachable only from the supervisor node through the internet, through a firewall. The Syslog protocol,
especially over UDP, is unreliable and insecure. You can deploy a collector behind the firewall to solve these
issues. The collector registers with the FortiSIEM supervisor node and then receives commands from the
supervisor regarding discovery and data collection.

Advanced Analytics 6.3 Study Guide 45

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Collectors are available as a virtual device, ISO image, and hardware device. If you use the VM image, you
can increase the vCPU and memory to handle greater loads. FortiSIEM becomes an essential core tool in
your security operations center (SOC) environment, and its use will likely grow over time as the corporate
infrastructure grows. Designing the FortiSIEM deployment to accommodate this increase in use over time
helps to ensure continued system performance, and minimizes the need to re-architect the system in the
future. For that reason, you should not decrease resources because there could be a performance impact
resulting in collector failure.

Advanced Analytics 6.3 Study Guide 46

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

You can monitor the status of the collectors on the page shown on this slide. Collectors run a reduced set of
system processes, compared to a supervisor or a worker. The processes that run on a collector are for
specific functions, such as discovery, performance monitoring, event parsing, and log data collection.

Advanced Analytics 6.3 Study Guide 47

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

The collector parses the logs and forwards the compressed logs to the supervisor or worker nodes over an
encrypted HTTPS channel. The collector also buffers the logs locally for a period of time, if the network
connection to the super or worker is not available.

The collector uploads events every five seconds or 10 MB, whichever is reached first. FortiSIEM is a real-time
system, so it attempts to minimize event delay and optimize the send. It is five seconds for low EPS
environments, and 10 MB for high EPS environments. The compression ratio is 8:1, which is accomplished by
standard zlib, which is an algorithm used for data compression.

Advanced Analytics 6.3 Study Guide 48

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

The collector enriches each event with a collector ID, organization ID, and name. The collector name is not
added during the event enrichment process. Because the collector performs the enrichment process, it saves
resources on the supervisor node. Having a collector in your environment makes it convenient for MSSP
administrators to query for logs and incidents related to your organization, because all logs being generated
from your organization are tagged with the unique collector ID, organization ID, and organization name.

Advanced Analytics 6.3 Study Guide 49

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Collectors have a built-in mechanism to buffer events in case there is WAN link failure and you lose
connection to the FortiSIEM cluster. Buffer size is dependent upon the EPS being received. Collectors will
ship the logs automatically when the link becomes available again.

By default, there are a maximum of 10,000 event files that are buffered on the collector. Each event file
contains five seconds’ worth of events and is limited to 10 MB in size before compression. The average event
size is estimated to be 200 Bytes, which depends on the device type and event.

Advanced Analytics 6.3 Study Guide 50

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

This slide shows an example of the estimated time that it would take for the collector to reach the maximum
buffer size for a 2000 EPS license. As you increase the EPS, the buffer storage fills up. The collector drops
events when the buffer is full.

Advanced Analytics 6.3 Study Guide 51

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about deploying collectors in a multi-tenant environment.

Advanced Analytics 6.3 Study Guide 52

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

When a collector is initially deployed, it is in an unconfigured state. To deploy the collector, you must know
which customer it belongs to, where it will upload data, and how long it is valid.

You can define all the required information during the collector registration process.

Advanced Analytics 6.3 Study Guide 53

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In a single virtual appliance (VA) setup with one supervisor node, specify the supervisor node as the data
upload destination for collectors. This is not recommended in larger setups because it can potentially overload
the single supervisor node.

Advanced Analytics 6.3 Study Guide 54

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In a FortiSIEM cluster, you can specify one or more worker nodes using the worker IP addresses. The
collectors load balance across the specified worker nodes. In this manner, streaming analytics, like inline
reports and rules, are distributed over the worker nodes. The best practice is to upload all the data to the
worker nodes and leave the supervisor node for performing other important tasks.

Advanced Analytics 6.3 Study Guide 55

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

You cannot define collectors before you set the worker upload address. Collectors receive the worker upload
address during registration and this value tells the collector to which node it should upload the data. If you
don’t have a worker, then you must at least define the supervisor as a worker.

Advanced Analytics 6.3 Study Guide 56

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

You can install workers as VA or hardware devices. After you deploy a VA worker for the first time, you must
run the configFSM.sh script to configure the time zone and network configuration. To run the setup script,
log in to the worker as root user and enter the commands shown on this slide. The setup script guides you
through the network configuration where you configure the IP address, gateway, DNS, and hostname.

Advanced Analytics 6.3 Study Guide 57

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

If you don’t have a worker node, then you must define the IP address of the supervisor node as a worker
address, so that you can add collectors to the cluster. For larger software-based deployments that involve
multiple collectors, a large number of monitored devices, or devices with high event rates, it is highly
recommended that you deploy one or more workers to distribute workload of the supervisor node. Note that
you can’t add workers to hardware-based appliances.

Advanced Analytics 6.3 Study Guide 58

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Each value in the worker upload address must listen on TCP port 443 for connections from collectors. The
more workers you add to the cluster, the more addresses that must be published to the internet. On the data
center firewall, create virtual IPs that map the external public IP to the worker private IP address. Collector
communication is only one way, so the customer firewall policies must allow all outbound traffic from the
collectors on port 443.

Advanced Analytics 6.3 Study Guide 59

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In a highly scalable design for large providers, you can place a load balancer behind the data center firewall.
You can create a static NAT on the data center firewall, to map the public IP address to the IP address of the
load balancer. That public IP address is the worker upload address for all the customer collectors. The load
balancer should evenly distribute the customer data to the workers in the FortiSIEM cluster.

Advanced Analytics 6.3 Study Guide 60

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Even though collectors send data directly to the workers, they still communicate periodically with the
supervisor node.

Collectors use the same communication channel that is used for sending the log data is also used to ask for
any tasks, such as discovery, test credentials, parser changes, custom performance monitoring tests, and
more, from the supervisor node. The supervisor node uses the same session to communicate with the
collectors. You need to allow only an outbound connection in the customer firewall policy. The supervisor
does not explicitly initiate any connections to the collector nodes.

Advanced Analytics 6.3 Study Guide 61

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

You must allow only TCP port 443 for the collector to communicate to the FortiSIEM cluster. Collector health
information and tasks are sent only to the supervisor, and the event data is sent to all nodes that are defined
in the worker upload settings. If the supervisor is also a worker, then the supervisor also receives event data.

Advanced Analytics 6.3 Study Guide 62

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about the data ingestion mechanism on FortiSOAR, and various settings
available for fine-tuning data ingestion and field mapping within a FortiSOAR module.

Advanced Analytics 6.3 Study Guide 63

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

You can use the data ingestion wizard to simplify data ingestion configuration and mapping of fields between
the two systems. The wizard fetches sample data from the source, mapping fields from the source data into a
FortiSOAR module, and setting up an ingestion schedule if the connector is enabled for scheduling. Based on
the inputs you provide in the wizard, the system dynamically generates the ingestion workflows without the
user being exposed to the details of playbooks, and easing the process of configuring ingestion.

Advanced Analytics 6.3 Study Guide 64

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Data ingestion can run in one of three modes:

• Notification based
• Schedule based
• App push

When running in notification-based mode, connectors such as IMAP, Exchange, Syslog, and so on, have a
notification service that is instantly notified when a message arrives on the server. In turn, the notification
service triggers a FortiSOAR playbook to create FortiSOAR records from the fetched data.

When running in schedule-based mode, connectors such as QRadar, Anomali, ServiceNow, and so on, use
the fetch APIs of the integration. By default, these fetch playbooks are scheduled to run every five minutes,
which the user can modify to run according to a user-defined interval. Note that most integrations that support
a notification-based ingestion also support a schedule-based ingestion. However, you must configure only one
of the two, otherwise both pull data from the same source, which might result in data loss due to conflicts.

When running in app push mode, connectors, such as Splunk, have a FortiSOAR add-on that you can install
on the server side to push data from the server to FortiSOAR. You configure the add-on with a user password
or appliance-based authentication in FortiSOAR and it triggers FortiSOAR playbooks to create the records in
FortiSOAR.

Advanced Analytics 6.3 Study Guide 65

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

Any connector that supports data ingestion has a Configure Data Ingestion tab. The Connectors page has
a section for data ingestion connectors that monitors the data ingestion and provides information on which
connectors are configured for using the Data Ingestion Wizard, as well as other information, such as the
status of a configuration, the schedule for ingestion, when data was last pulled using that configuration, and so
on.

Sample ingestion playbooks were created keeping the following points in mind:
• Each playbook that contributes to data ingestion contains tags such as <connector_name> and
<dataingestion>.
• Fetch Playbook: This playbook fetches sample data and is also used for the actual fetch operation once
ingestion is configured.
• Data from external systems is presented to the users as source data on the Field Mapping screen in the
data ingestion wizard.

Advanced Analytics 6.3 Study Guide 66

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

There are data ingestion connectors, such as Fortinet FortiSIEM, that include sample playbooks that can
fetch data from a SIEM or other data aggregation systems. You can use these sample playbooks in other
playbook environments. If you decide to use the sample playbooks in your environment, ensure that you clone
those playbooks and move them to a different collection, since the sample playbook collection gets deleted
during connector upgrade and delete.

Advanced Analytics 6.3 Study Guide 67

 Defining FortiSOAR, Collectors and Agents

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned about defining and deploying collectors. You
also learned about collector operation, and scaling collectors as organizations grow.

Advanced Analytics 6.3 Study Guide 68

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about installing collectors on various platforms, registering collectors on
FortiSIEM, and discovering devices with collectors. You will also learn about managing events per second
(EPS) assignment for collectors.

Advanced Analytics 6.3 Study Guide 69

 Operating Collectors

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in EPS and collector installation, you should be able to identify EPS
requirements for collectors, the impact of an excessive number of collectors on a FortiSIEM cluster, and
troubleshoot collector installation.

Advanced Analytics 6.3 Study Guide 70

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about collector architecture, the minimum guaranteed EPS for collectors, and the
overall super EPS.

Advanced Analytics 6.3 Study Guide 71

 Operating Collectors

DO NOT REPRINT
© FORTINET

One of the ways of defining an organization is by associating it with a collector. The organization’s collector
monitors all devices belonging to that organization, as well as all events.

The Guaranteed EPS setting sets the threshold at which events are always accepted, as long as the event
rate is below the configured value. FortiSIEM reallocates excess EPS, which is the licensed rate minus the
sum of guaranteed EPS across all collectors. It is based on need, but the allocation never goes below the
configured guaranteed EPS value.

The start and end time settings specify the dates during which the collector is active.

Advanced Analytics 6.3 Study Guide 72

 Operating Collectors

DO NOT REPRINT
© FORTINET

Sometimes concerns may be made over the amount of bandwidth used or available for collector uploads. You
can configure the maximum upload bandwidth value to address those concerns. The default value is
unlimited.

Advanced Analytics 6.3 Study Guide 73

 Operating Collectors

DO NOT REPRINT
© FORTINET

FortiSIEM comes preconfigured with a minimum guaranteed EPS. It is set to 20 in the

phoenix_config.txt file on the supervisor. So, if you configure an EPS lower than the minimum value,
FortiSIEM automatically changes the value to the match the minimum value when you try to save the
changes.

Advanced Analytics 6.3 Study Guide 74

 Operating Collectors

DO NOT REPRINT
© FORTINET

The purchased EPS licenses are treated like a pool, which you have to distribute across all collectors. The
guaranteed EPS value for each collector is deducted from the overall purchased FortiSIEM EPS value.

For example, if you’ve purchased a 1000-EPS license and configured a new collector with 100 EPS for
customer A, 900 EPS remain in the pool. If you add another collector with 500 EPS for customer B, 400 EPS
remain in the pool. You can use the remaining EPS pool for future customer collectors, or use it for your own
organization to monitor and manage local assets.

Advanced Analytics 6.3 Study Guide 75

 Operating Collectors

DO NOT REPRINT
© FORTINET

If the overall total licensed system EPS is exceeded during the guaranteed EPS definition for a collector, then
errors are reported. For example, if you purchased a 15,000-EPS license and you try to allocate more than
that value to a single collector, then you will get an error stating that you have reached the total EPS limit for
the whole system.

Advanced Analytics 6.3 Study Guide 76

 Operating Collectors

DO NOT REPRINT
© FORTINET

A super organization needs its own EPS to manage its own assets. A service provider may have critical
assets within its own organization that must be monitored. For that reason, it’s always a good idea to reserve
some EPS for the service provider’s own needs.

Advanced Analytics 6.3 Study Guide 77

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about installing a collector and then registering it on the supervisor.

Advanced Analytics 6.3 Study Guide 78

 Operating Collectors

DO NOT REPRINT
© FORTINET

You can install collectors as VA or hardware appliances. After you deploy a VA collector for the first time, you
must run the configFSM.sh script to configure the time zone and the network configuration. To run the
setup script, log in to the collector as root user, and then enter the commands shown on this slide. The setup
script guides you through the network configuration where you configure the IP address, gateway, DNS, and
hostname.

Advanced Analytics 6.3 Study Guide 79

 Operating Collectors

DO NOT REPRINT
© FORTINET

After you complete the collector installation, you must register the collector on the supervisor. Before
registration, you must collect information from the organization definition setting of the supervisor, such as
organization name, administrator user, and administrator password. After you have that information, use the
commands shown on this slide to register the collector on the supervisor.

Advanced Analytics 6.3 Study Guide 80

 Operating Collectors

DO NOT REPRINT
© FORTINET

After you register the collector, check the status on the supervisor GUI. The Show Processes tab displays
the processes running on the collector and their status, up time, CPU, memory, and more.

Advanced Analytics 6.3 Study Guide 81

 Operating Collectors

DO NOT REPRINT
© FORTINET

Before a collector is registered, most processes are down. The services start up only after the collector is
registered successfully on the supervisor.

Advanced Analytics 6.3 Study Guide 82

 Operating Collectors

DO NOT REPRINT
© FORTINET

Once a collector is registered to a supervisor, it pulls a license file from the supervisor. The file is saved to the
directory location shown on this slide. You should not remove this file because doing so can take down the
collector processes.

Advanced Analytics 6.3 Study Guide 83

 Operating Collectors

DO NOT REPRINT
© FORTINET

Registration populates the collector configuration file with information, such as the cloud URL address of the
supervisor, customer ID, agent ID, and worker upload address.

Advanced Analytics 6.3 Study Guide 84

 Operating Collectors

DO NOT REPRINT
© FORTINET

The Postgres database on the supervisor records a natural ID for the collector, which is actually the local
UUID. The local UUID on the collector is recorded in the product_uuid file, the location for which is shown
on this slide. The supervisor stores this value in a Postgres table along with the name, organization ID, and
collector ID.

You can view the Postgres table by running the command shown on this slide. The output shows a table
listing all of the collectors registered to the supervisor. If your collector is listed but it won’t connect, then there
was a problem during registration, which you should investigate.

Advanced Analytics 6.3 Study Guide 85

 Operating Collectors

DO NOT REPRINT
© FORTINET

Old configuration settings and license files can prevent a collector from reregistering. If the collector won’t
reregister, then you must clear the collector natural ID from the Postgres table on the supervisor. This is a
multistep process that requires console and SSH access to the supervisor and collector.

Advanced Analytics 6.3 Study Guide 86

 Operating Collectors

DO NOT REPRINT
© FORTINET

Log in to the Postgres on the supervisor using the commands shown on this slide. You must identify the
correct customer collector name that needs to be cleared. The name of the collector in the example shown on
this slide is OrgA_Collector. To clear the natural ID, use the last set of commands shown on this slide,
which replaces the natural_id with none for the collector.

Advanced Analytics 6.3 Study Guide 87

 Operating Collectors

DO NOT REPRINT
© FORTINET

Now, you must remove the license that was associated with the collector. Identify the license name that is
located in the opsd directory on the collector and remove it. Then, restart the phMonitor process by
stopping the process, which restarts it automatically. Finally, register the collector just as you would register a
new collector.

Advanced Analytics 6.3 Study Guide 88

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about discovering devices with the collector.

Advanced Analytics 6.3 Study Guide 89

 Operating Collectors

DO NOT REPRINT
© FORTINET

The customer's specific, on-premises collectors perform device discoveries on customer networks. This forms
a one-to-one relationship between devices and the collector for all further tasks, such as performance and
availability jobs, or pull event jobs, such as WMI event log collection.

Advanced Analytics 6.3 Study Guide 90

 Operating Collectors

DO NOT REPRINT
© FORTINET

To form the one-to-one relationship between devices and the collector, you must define the device credentials
for that specific organization and associate them with the applicable IP ranges. Collectors for that organization
use the credentials that you defined for discovery, connectivity tests, and data collection jobs.

Advanced Analytics 6.3 Study Guide 91

 Operating Collectors

DO NOT REPRINT
© FORTINET

If a customer has multiple collectors, you can associate credentials and discovery targets with specific
collectors. Only the collector that you associate the credentials with can discover devices for the IP range so
that devices do not get duplicated in the CMDB. After you discover the devices, you can view which device
was discovered by which collector.

Advanced Analytics 6.3 Study Guide 92

 Operating Collectors

DO NOT REPRINT
© FORTINET

The CMDB provides a filter to view which devices are associated with each customer collector. If you select
Discovered by All, then all the devices discovered by all the collectors for that organization are displayed.
You can also select the individual collector alone, which shows only the devices discovered by that specific
collector.

Advanced Analytics 6.3 Study Guide 93

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about scaling customers with collectors.

Advanced Analytics 6.3 Study Guide 94

 Operating Collectors

DO NOT REPRINT
© FORTINET

If you need to scale collectors at a customer location, you must take two things into consideration. The first is
direct log collection from devices that report syslog messages to collectors. The second is performance
monitoring jobs that are performed by the collector by polling devices using SNMP or the WMI protocol.

Advanced Analytics 6.3 Study Guide 95

 Operating Collectors

DO NOT REPRINT
© FORTINET

As the incoming EPS received by collectors increases, you must deploy more collectors, or increase the
resources on the existing collectors. For example, for an incoming EPS of 10,000, the collector needs at least
16 vCPU and 16 GB of RAM.

Advanced Analytics 6.3 Study Guide 96

 Operating Collectors

DO NOT REPRINT
© FORTINET

For polling jobs, the collector uses either SNMP or the WMI protocol. Unlike syslog, where the devices sent
logs to the collector, the SNMP and WMI protocols require the collector to poll the devices periodically for
performance and security metrics. The fact that the collector must actively poll devices requires additional
processing overhead. You should not have more than 300 devices per collector for SNMP polling. If you’re
using SNMPv3, then that device limit is even lower because SNMPv3 is more resource intensive. You should
not have more than 100 devices per collector when using WMI event log collection. You must add more
collectors if the number of devices that you are monitoring keeps growing.

Advanced Analytics 6.3 Study Guide 97

 Operating Collectors

DO NOT REPRINT
© FORTINET

As you keep adding collectors to organizations to scale their growth, you also must take into account the
FortiSIEM cluster processing load. With more EPS to process, the cluster needs additional processing power.
For that, you should add more workers. Ideally, you should add a new worker for every 10,000 increase in
EPS.

Advanced Analytics 6.3 Study Guide 98

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about upgrading collectors.

Advanced Analytics 6.3 Study Guide 99

 Operating Collectors

DO NOT REPRINT
© FORTINET

Collectors should, at a minimum, be on the same major release as the supervisor and workers. For example,
if the supervisor and worker cluster is on version 6.2.1, the collectors could be on version 6.2.0. If the
supervisor and worker cluster is on version 5.2.5, collectors should not be on version 4.10 or issues may
arise. Major releases sometimes introduce new functionality that collectors on older releases may not support.
Always follow the upgrade process mentioned in the Upgrade Guide found on docs.fortinet.com.

Advanced Analytics 6.3 Study Guide 100

 Operating Collectors

DO NOT REPRINT
© FORTINET

Before you can begin to upgrade collectors for organizations, you must prepare the supervisor so that the
collectors can download the upgrade image from the supervisor and then upgrade itself. Create an upgrade
directory on the supervisor under the opt directory. Download the upgrade zip package from the Fortinet
support site, and then upload it to the supervisor node under the /opt/upgrade/ folder. Prepare the
collector upgrade image by running the command on the supervisor, as shown on this slide.

Advanced Analytics 6.3 Study Guide 101

 Operating Collectors

DO NOT REPRINT
© FORTINET

The service provider administrator who is logged in to the supervisor instructs the collector to download the
collector upgrade image. The supervisor gives the collector a task to download the image from a reachable
image server URL, which, in this case, is the supervisor. The collector downloads the new image. The service
provider administrator then instructs the collector to upgrade itself.

Advanced Analytics 6.3 Study Guide 102

 Operating Collectors

DO NOT REPRINT
© FORTINET

Log in to the FortiSIEM GUI and navigate to the Collector Health page. Select the collector that you want to
upgrade and click Action. In the drop-down list, select Download Image, which instructs the collector to
download the collector upgrade image. The service provider administrator then instructs the collector to
upgrade itself by clicking Install Image.

Advanced Analytics 6.3 Study Guide 103

 Operating Collectors

DO NOT REPRINT
© FORTINET

In this section, you will learn about EPS architecture.

Advanced Analytics 6.3 Study Guide 104

 Operating Collectors

DO NOT REPRINT
© FORTINET

FortiSIEM is a distributed system where events can be received at any node, such as a supervisor, worker, or
collector. One of the key requirements for FortiSIEM licensing is the aggregate EPS that FortiSIEM receives.
FortiSIEM calculates EPS over a three-minute period. The total number of events received over a three-
minute period is divided by 180. So, sometimes EPS is referred to as events within a three-minute time
period.

Advanced Analytics 6.3 Study Guide 105

 Operating Collectors

DO NOT REPRINT
© FORTINET

You define the guaranteed EPS during the collector configuration process while setting up an organization.
FortiSIEM ensures that the collector can always send EPS at this rate. This is a constant that never changes
during the operation of the collector, unless you modify the collector definition. UEBA events are not counted
toward EPS.

Advanced Analytics 6.3 Study Guide 106

 Operating Collectors

DO NOT REPRINT
© FORTINET

Incoming EPS is the EPS that the collector sees, and this value changes continuously. Every collector
periodically reports the incoming EPS to the supervisor. You can view this metric for the collector on the
Collector Health page.

Advanced Analytics 6.3 Study Guide 107

 Operating Collectors

DO NOT REPRINT
© FORTINET

Usually, if the incoming EPS is greater than the guaranteed EPS, then the collector begins to drop events until
the incoming EPS is less than or equal to the guaranteed EPS. However, features such EPS bursting have
been developed over time to help service providers avoid this scenario.

Advanced Analytics 6.3 Study Guide 108

 Operating Collectors

DO NOT REPRINT
© FORTINET

Before firmware version 4.10, FortiSIEM dropped events that exceeded 110% of the licensed EPS. Starting
with the 4.10 release, FortiSIEM adds a reservoir of events to reduce the possibility of events being dropped.
This allows greater EPS bursts without event loss. FortiSIEM lets you burst up to five times the licensed EPS
using the currently accumulated unused EPS. To benefit from this EPS bursting, you must have enough
computational power and storage to process the extra EPS. You must provision the system with five times the
licensed EPS to handle potential event surges.

Advanced Analytics 6.3 Study Guide 109

 Operating Collectors

DO NOT REPRINT
© FORTINET

When a node is first deployed, the allowed events is the same as the licensed EPS value for a three-minute
duration. This example is based on a 520 EPS license, so the allocated EPS for a three-minute duration is
10,2960, which includes the 10% buffer.

Advanced Analytics 6.3 Study Guide 110

 Operating Collectors

DO NOT REPRINT
© FORTINET

Over the course of the day, the incoming and used EPS fluctuates, but it should be within your purchased
license limit during normal operation.

Advanced Analytics 6.3 Study Guide 111

 Operating Collectors

DO NOT REPRINT
© FORTINET

FortiSIEM keeps track of unused EPS as the sum of positive differences of allocated EPS and incoming EPS
over all nodes. FortiSIEM can use unused EPS for bursting during attacks or other event surge periods,
beyond licensed EPS.

Advanced Analytics 6.3 Study Guide 112

 Operating Collectors

DO NOT REPRINT
© FORTINET

At the end of every three-minute interval, incoming EPS is calculated at each event entry node—collector,
worker, or supervisor—and the value is sent to the central decision-making engine on the supervisor node.
The supervisor calculates the unused events by subtracting the total incoming events from the licensed EPS.
In the example shown on this slide, the total incoming EPS from the three collectors is 175. Over a three-
minute duration, that is 31,500 events. The total unused events is 71,460, which is added to the EPS
reservoir.

Advanced Analytics 6.3 Study Guide 113

 Operating Collectors

DO NOT REPRINT
© FORTINET

FortiSIEM creates a reservoir of events to use during event bursts. The supervisor receives the incoming EPS
from all the nodes every three minutes, and that incoming EPS is the used EPS available to every node. The
unused EPS is calculated by subtracting the used EPS from the licensed EPS, which is a global value that
can be shared by any node in case there is a burst.

Advanced Analytics 6.3 Study Guide 114

 Operating Collectors

DO NOT REPRINT
© FORTINET

At midnight, the number of events than can be carried over to the next day is restricted to 50% and the
process of building the EPS reservoir starts over for the next day.

Advanced Analytics 6.3 Study Guide 115

 Operating Collectors

DO NOT REPRINT
© FORTINET

FortiSIEM can use events in the EPS reservoir if the system suddenly needs to process more than the
license.

The supervisor then computes the allocated EPS for the next three-minute interval for every node, and
communicates those values to every node. The total number of allowed events for the next three-minute
interval is the licensed EPS plus the unused reservoir value, with the bonus 10% buffer. Each node reports
the incoming EPS for the current interval to the supervisor node.

Advanced Analytics 6.3 Study Guide 116

 Operating Collectors

DO NOT REPRINT
© FORTINET

You can view the allowed, used, and unused values in the logs. This information is saved in the
phoenix.log file. Note that the allowed events and unused reservoir values keep increasing.

Advanced Analytics 6.3 Study Guide 117

 Operating Collectors

DO NOT REPRINT
© FORTINET

You can check the Licensed EPS, Used EPS, and Unused Events on the Usage page on the FortiSIEM
GUI.

Advanced Analytics 6.3 Study Guide 118

 Operating Collectors

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned about installing collectors on various
platforms, registering collectors on FortiSIEM, and discovering devices with collectors. You also learned about
managing events per second (EPS) assignment for collectors.

Advanced Analytics 6.3 Study Guide 119

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about installing and managing FortiSIEM Windows and Linux agents.

Advanced Analytics 6.3 Study Guide 120

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in Windows and Linux agents, you will be able to install and manage agents in
a multi-tenant environment.

Advanced Analytics 6.3 Study Guide 121

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about various FortiSIEM agent components and their features.

Advanced Analytics 6.3 Study Guide 122

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In all types of deployments, there is one supervisor node and optional worker and collector nodes, depending
on the type of architecture you’ve chosen to deploy. Beginning from FortiSIEM 5.2, the supervisor node has
an integrated agent manager component that manages FortiSIEM Windows and Linux agents.

Advanced Analytics 6.3 Study Guide 123

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Basic and Advanced is old terminology when referring to Windows agents. By default, the new Windows
agent supports all features. Features, such as installed software detection, registry change detection, file
integrity monitoring, extended WMI monitoring, PowerShell command output monitoring, and removable drive
monitoring are supported by the FortiSIEM Windows agent.

Advanced Analytics 6.3 Study Guide 124

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Linux agents can be used for FIM to detect file reads, writes, and edits with added user context. The agents
are installed on the servers individually, and centrally managed on the FortiSIEM GUI.

The agents use the auditd daemon on Linux. It is a component of the Linux auditing system that is
responsible for writing audit records to the disk. The audit daemon itself has some configuration options that
you can customize in the auditd.conf file.

Logs collected by the Linux agent are sent to a Syslog facility, such as a FortiSIEM collector, and the collector
delivers the logs over HTTPS to FortiSIEM.

Advanced Analytics 6.3 Study Guide 125

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

You need to have a license type that supports agents. You can check how many agents are supported in your
license on the FortiSIEM GUI. The number of agents supported is a global value and will be shared across
organizations. If you have more than 200 agents across all organizations that are managed by the supervisor,
then you need to upgrade the license to support additional agents.

Advanced Analytics 6.3 Study Guide 126

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about FortiSIEM agent architecture for service providers.

Advanced Analytics 6.3 Study Guide 127

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Agents use HTTPS to communicate directly with one or more dedicated customer collectors for log data,
while also reporting health information to the supervisor node only.

Advanced Analytics 6.3 Study Guide 128

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Agents use HTTPS to communicate directly with one or more multi-tenant collectors to send log data, while
also reporting health information to the supervisor node only.

Advanced Analytics 6.3 Study Guide 129

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about FortiSIEM agent installation on Windows and Linux platform. You will also
learn about the agent registration process with the supervisor node.

Advanced Analytics 6.3 Study Guide 130

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Windows agent is supported on Windows 7 Enterprise and Professional, Windows 8, Windows 10, Windows
Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016.

Linux agent is supported on CentOS 6.x and 7.x, Redhat Enterprise Linux 6.x and 7.x, Ubuntu 14, 16, 18,
Amazon Linux 1, and Amazon Linux 2.

Advanced Analytics 6.3 Study Guide 131

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Before you deploy an agent for an organization, you must define the agent credentials on the supervisor node.
The Agent User and Agent Password that you define for an organization will be used to validate agents
registering from that organization to the supervisor node.

Advanced Analytics 6.3 Study Guide 132

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

To install the Windows agent, first you must download two files from the Fortinet Support website—the agent
installer, and the agent registration XML file. Download both files to the same directory. You have to edit the
parameters for agent registration in the XML file. This includes the organization ID number and name,
supervisor IP address and port, and registration username and password. Finally, you can run the agent
installer.

Advanced Analytics 6.3 Study Guide 133

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

To install a Linux agent, you have to download the shell script for the Linux agent installer from the Fortinet
Support site. There are some dependencies you have to be aware of. Make sure you install the packages
listed on the slide before running the installer.

Once you have the dependent packages installed, run the shell script using the command shown on this slide.
The install script needs execute permissions and you must install it as a root user. Fill in the parameters such
as supervisor IP address, organization ID, organization name, agent username, and agent password.

Advanced Analytics 6.3 Study Guide 134

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

After the installation is complete, the agents will register with the supervisor node. The agent will belong to the
organization detailed in the InstallSettings.xml file for Windows platforms, or the command line
parameters for Linux platforms. An entry will appear in the CMDB for every agent that is installed and
registered with the supervisor node.

The registration between the agent and the supervisor node occurs over port 443. Make sure that any firewall
between the agent and the supervisor node permits HTTPS traffic on port 443.

Advanced Analytics 6.3 Study Guide 135

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The agents will continue to communicate with the supervisor node after the initial installation. The reason for
this communication is to report the agent status and to poll for any new agent templates. By default, every
agent will poll the supervisor node every minute.

Advanced Analytics 6.3 Study Guide 136

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

When the agent is registered, there is no template associated with the agent. The agent does not upload any
log data until a template is associated with it. When you assign a template to an agent, it will begin uploading
log data based on the parameters that are set in the template.

Advanced Analytics 6.3 Study Guide 137

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will explore various CMDB agent statuses from the time the agent is registered and when
a template is associated with the agent.

Advanced Analytics 6.3 Study Guide 138

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Once an agent is installed, it appears in the CMDB with the Method of AGENT. The Agent Status column
may display various states initially, depending upon whether a matching template is predefined or not.

Advanced Analytics 6.3 Study Guide 139

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

When an agent is registered successfully but has not received a monitoring template, the Agent Status
column will show Registered. At this point, a Windows agent license is not used and the device Status
column shows Unmanaged. As soon as a template is assigned to the agent, the device Status column will
change to Pending, just like the default status for any other device in the CMDB.

Advanced Analytics 6.3 Study Guide 140

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The same agent status messages apply to both Windows and Linux agents. This slide shows an example of a
Linux agent that has just been installed.

Advanced Analytics 6.3 Study Guide 141

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

When a template is associated with the agent, the Agent Status column will change to Running Active. At
this point, the agent is actively collecting logs from the device it is installed on and sending them to the
collector or supervisor node.

When the agent is running but does not have a template associated with it, the status will change to Running
Inactive. This could be related to a template being removed, template not being assigned, or collector not
being assigned.

Advanced Analytics 6.3 Study Guide 142

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

If the agent service is stopped on the device, then the Agent Status column will show Stopped. If, for some
reason, the agent is not communicating with the supervisor node because of network connectivity issues, then
the Agent Status column will show Disconnected. Any change in status may take up to one minute because
of the polling interval.

Advanced Analytics 6.3 Study Guide 143

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The Agent Status column will show Disabled if an administrator has disabled the agent. This status comes
from a CMDB action to Disable Agent, which removes any templates. Select Enable Agent to revert the
status.

Advanced Analytics 6.3 Study Guide 144

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

If the agent device has no performance templates assigned, then when the agent is uninstalled the device is
removed from the CMDB. If the agent device has performance jobs assigned, then the device remains in the
CMDB and the Agent Status and Agent Policy columns become empty.

Advanced Analytics 6.3 Study Guide 145

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

This slide shows a summary of the various agent statuses. These statuses apply to both Windows and Linux
agents.

Advanced Analytics 6.3 Study Guide 146

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about Windows agent templates and the types of templates that can be assigned
to a Windows agent.

Advanced Analytics 6.3 Study Guide 147

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Templates are defined on the FortiSIEM GUI. Templates define what type of logs the agent will monitor and
upload, such as security event logs, system event logs, DNS logs, DHCP logs, custom application logs, file
integrity monitoring logs, and so on.

You can assign one or more templates to the same agent and the configuration will be merged. For example,
you might use template 1 to collect Windows event logs, and use template 2 to collect Windows event logs
and application logs from DNS and DHCP, and so on.

Advanced Analytics 6.3 Study Guide 148

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

You can create one or more templates and use it across multiple customers. You must be logged in as
FortiSIEM super admin to create templates, and the template name must not contain spaces.

Advanced Analytics 6.3 Study Guide 149

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

On the Event tab, you can define which event logs to collect, such as security, system, or application. You
can filter all event logs by specifying a semi-colon separated list of event IDs, as either an include or exclude
list.

Advanced Analytics 6.3 Study Guide 150

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

On the windows agent template enable UEBA to instruct the windows agent to collect UEBA logs. You must
have UEBA Telemetry License to allow the windows agent to collect UEBA logs.

Advanced Analytics 6.3 Study Guide 151

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

A Windows system audit policy determines which type of information about the system you'll find in the
security logs. Windows uses nine audit policy categories and 50 audit policy subcategories to give you more
granular control over which information is logged.

Advanced Analytics 6.3 Study Guide 152

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

At a minimum, Fortinet recommends that you enable the Audit account logon events and Audit logon
events policies for auditing logon activity. Enable Audit object access events for auditing access to files and
folders. Enable Audit system events for system up and down status messages. Most forensic data requires
you to enable additional policies.

Advanced Analytics 6.3 Study Guide 153

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The purpose of security auditing is to ensure that events are logged whenever an activity occurs. However,
when every activity is audited, event logs become flooded with irrelevant information that makes it difficult for
network administrators to separate critical events from insignificant ones. Advanced audit policy settings help
administrators exercise granular control over which activities get recorded in the logs, helping cut down on
event noise.

For example, instead of turning on the DS Access audit policy category to troubleshoot a replication
problem—which would generate around eight events every time this activity occurs—an administrator could
turn on the advanced audit policy subcategory for directory service replication, which would only generate one
event instead of eight.

Do not fall for the recommendation to enable only failure events for each category. A common misconception
is that a failure-only audit policy will alert you to all suspicious events. In reality, many of the most important
events in the security log—events such as changes to critical user accounts and groups, account lockouts,
and changes to security settings—are success events.

Advanced Analytics 6.3 Study Guide 154

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Event 4688 documents each program that is executed, who the program ran as, and the process that started
this process.

When you start a program, you are creating a process that stays open until the program exits. This process is
identified by the process ID. You can correlate this event to other events by the process ID to identify what the
program did while it ran and when it exited. This is crucial for identifying malicious use of standard operating
system commands.

Advanced Analytics 6.3 Study Guide 155

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Not all these categories are suitable for collection by FortiSIEM because some are capable of creating huge
volumes of events just like a debug command on a busy firewall.

Admin log types are useful for troubleshooting, targeted at end users, administrators, and support personnel.
Operational log types are useful for analyzing and diagnosing a particular problem or occurrence. Analytic
log types are events published in a high volume that trace an issue. Debug log types are used by developers
to troubleshoot issues with applications.

By default, both analytic and debug logs are hidden and disabled.

Advanced Analytics 6.3 Study Guide 156

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

You need additional event logging to identify bad actors or malware that might get into your network. By
analyzing the logs, FortiSIEM should be able to track their entry point, identify whether they spread between
systems, and identify what happened on a particular system. The default built-in Windows event logs make it
hard to answer these questions. There is limited information captured for process creation and DLL loading.
Network connection information is also limited. There is also no way to capture common attacker behavior,
such as thread injection.

Advanced Analytics 6.3 Study Guide 157

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Similar to Windows agents, you can also create one or more templates for Linux agents that can be used
across multiple customers.

Advanced Analytics 6.3 Study Guide 158

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

On the Linux template, you can select a Syslog facility and the severity levels for collection.

The facility represents the machine process that created the Syslog event. For example, is the event created
by the kernel, mail system, security, or authorization processes? The facility represents a filter instructing the
agent to forward only those events whose facility matches the one defined in this field. So, by changing the
facility and the severity level, you change the number of messages that are sent by the agent.

Advanced Analytics 6.3 Study Guide 159

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The Log File specifies the path to the files or directories that will be monitored. The Log Prefix will be
inserted into the Syslog header when delivered to FortiSIEM.

Advanced Analytics 6.3 Study Guide 160

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

You can use file integrity monitoring to make sure that critical files and directories on servers are not modified.
The Modify action will contain an MD5 hash code for the new file. By default, the agent will not perform any
file integrity monitoring on the root directory. You can also push the modified file to FortiSIEM and you could
also compare the hash of the modified file with a baseline file.

Advanced Analytics 6.3 Study Guide 161

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The Process Monitoring on Linux template is used collect events and logs related to process status on Linux
devices.

Advanced Analytics 6.3 Study Guide 162

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

In this section, you will learn about associating a template with a host.

Advanced Analytics 6.3 Study Guide 163

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Devices from each organization are assigned one or more templates and one or more collectors. Agents will
load balance logs across multiple collectors. For example, if a template is assigned to multiple devices for a
customer with multi-tenant collectors, then the agents will load balance logs across all the collectors defined
for that customer.

Advanced Analytics 6.3 Study Guide 164

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

When you associate a host with a template, you have the option to select an organization with or without a
collector. If an organization is selected with a dedicated collector, other organizations will be grayed out. If you
select organizations without a collector, then FortiSIEM will allow any multi-tenant collector to be assigned.
You can assign the template to any device within the organization, or you could select specific devices from
the CMDB.

You can select a single template or multiple templates. If you select multiple templates, then the configuration
will be merged. You can select a specific collector or multiple collectors for that organization. If you select
multiple collectors, then logs sent by the agents will be load balanced across the collectors.

The first policy to match each agent will be used. You can move the policy order up or down. For the policy to
take affect you must click Apply.

Advanced Analytics 6.3 Study Guide 165

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

The same rules apply to Linux agents. Policies are evaluated in order, where lower order is higher priority.
The policy that matches first is selected.

Advanced Analytics 6.3 Study Guide 166

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

Agents will periodically check in with the supervisor every minute and collect any new template associations.
It may take more than a minute for a new template to take effect.

Advanced Analytics 6.3 Study Guide 167

 Windows and Linux Agents

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned about installing and managing FortiSIEM
Windows and Linux agents.

Advanced Analytics 6.3 Study Guide 168

 Rules

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about rules, including subpatterns in a rule and the backend process that is
involved in evaluating rules and triggering incidents. You will also learn about the sliding time window in a rule,
out-of-box rules, and how each rule time window may be different.

Advanced Analytics 6.3 Study Guide 169

 Rules

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding rules, you will be able to identify the purpose of each rule that
is built into FortiSIEM. Also, by understanding the structure of rules you will be able to create your own custom
rules.

Advanced Analytics 6.3 Study Guide 170

 Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn the basics of rule breakdown.

Advanced Analytics 6.3 Study Guide 171

 Rules

DO NOT REPRINT
© FORTINET

FortiSIEM rules track events to trigger incidents based on various availability, performance, and security
issues in your environment.

There are three kinds of rules—event-based, baseline, and UEBA. Event-based rules are based on tracking
real-time events against defined thresholds. Baseline rules are based upon determining if something is now
abnormally different against a learned baseline of past behavior. UEBA rules are based upon AI and ML
algorithm.

All rules are composed of subpatterns that track events over a specified time window and are evaluated in
memory.

Advanced Analytics 6.3 Study Guide 172

 Rules

DO NOT REPRINT
© FORTINET

Rule subpatterns consists of a filter, group by, and aggregate condition. A rule could have one or many
subpatterns to be evaluated. The subpattern determines what data will be evaluated, under what conditions
there should be a match, and how many different matches have taken place.

Advanced Analytics 6.3 Study Guide 173

 Rules

DO NOT REPRINT
© FORTINET

A subpattern defines the characteristics of events that will cause a rule to trigger an incident. A subpattern
involves defining event attributes that will be monitored, and then defining the threshold values for
aggregations of event attributes that will trigger an incident.

You can think of the subpattern filter just like a SQL query, where the whole FortiSIEM event database is a
huge table with many columns that are not all populated with data because every event contains different
values.

Advanced Analytics 6.3 Study Guide 174

 Rules

DO NOT REPRINT
© FORTINET

The parameters that you specify in the event filter eventually translate to a SQL query. This slide shows
multiple columns with different event attributes and values. If a certain attribute does not apply to an event and
there is no value for that attribute, then it will be populated with a NULL value.

In the Event Filter, if you select Event Type as the attribute and enter the value shown on this slide,
FortiSIEM translates that into a SQL statement to query the table. It will filter out other events and evaluate
those events where traffic was allowed by FortiGate.

Advanced Analytics 6.3 Study Guide 175

 Rules

DO NOT REPRINT
© FORTINET

This slide shows another performance monitoring event type related to CPU utilization. FortiSIEM will
translate the filter into a SQL query, which is shown on this slide. It will filter out other events and evaluate
only those events that are related to CPU utilization.

Advanced Analytics 6.3 Study Guide 176

 Rules

DO NOT REPRINT
© FORTINET

This slide shows another example using the NOT IN operator with the Attribute set as Destination TCP/UDP
Port with a Value of 80,443. The resulting SQL statement is shown on this slide.

This query will return all events whose destination TCP and UDP port is not 80 or 443, which means all
events whose destination port is not related to HTTP or HTTPS traffic.

Advanced Analytics 6.3 Study Guide 177

 Rules

DO NOT REPRINT
© FORTINET

The rule filter will filter out events that are of interest for evaluating a rule, and group by will group all those
events based on the attributes that you define in the Group By field.

In this example, user Terry was found in three events but, from those three events, two of the events match
the group by attribute with a common source IP, reporting IP, and user. Think of this as a single SQL output
row for each group with a COUNT.

Advanced Analytics 6.3 Study Guide 178

 Rules

DO NOT REPRINT
© FORTINET

This slide shows an example event type filter for FortiGate SSL VPN logon failures. The group by attributes
are set as source IP, reporting IP and user.

In the example shown on this slide, the user Admin has two entries with the same source IP and reporting IP.
So, based on the group by definition, those two entries will be grouped as one.

Similarly, user Bryan has two entries with the same source IP and reporting IP. So, those two entries will also
be grouped as one.

Advanced Analytics 6.3 Study Guide 179

 Rules

DO NOT REPRINT
© FORTINET

This slide shows the same event filter example, but this time there is an additional count column. The filter is
still searching for FortiGate SSL VPN logon failures, and the group by attributes are set as source IP,
reporting IP, and user.

The count column will display the number of times the event was repeated for the same source IP, reporting
IP, and user.

In the results, the user Bryan had SSL VPN logon failures from the same source IP and it was reported twice,
which you can see in the corresponding COUNT column.

Advanced Analytics 6.3 Study Guide 180

 Rules

DO NOT REPRINT
© FORTINET

The aggregate condition is used to perform calculations on the matching data and return a single result. The
typical SQL aggregate functions are supported. Some of these supported functions are shown on this slide.

Advanced Analytics 6.3 Study Guide 181

 Rules

DO NOT REPRINT
© FORTINET

Take a look at the same event filter example shown on this slide. This time, the group by condition is
configured to restrict the number of results, which means that only events with same source IP, reporting IP,
and user, as long as the count is equal to or greater than 3, will be evaluated by the rule.

Advanced Analytics 6.3 Study Guide 182

 Rules

DO NOT REPRINT
© FORTINET

You can also have multiple aggregate conditions using the next operator. If multiple conditions are specified,
then a next logical operator must be defined using AND or OR.

In the example table shown on this slide, FortiSIEM needs three or more CPU utilization events to calculate
average CPU utilization, and then trigger an incident if the average is greater than or equal to 95. This
compound rule is built using the AND operator.

Advanced Analytics 6.3 Study Guide 183

 Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about rule processes and rule process architecture.

Advanced Analytics 6.3 Study Guide 184

 Rules

DO NOT REPRINT
© FORTINET

All FortiSIEM rules processing is performed in memory. There are two backend processes involved—
phRuleWorker and phRuleMaster. There can be many phRuleWorker processes but only one phRuleMaster
in a FortiSIEM deployment. This is how FortiSIEM is able to correlate events from multiple devices and
locations no matter where the data was actually received.

The phRuleWorker exists on both the supervisor and workers. The phRuleWorker process evaluates non-
aggregate conditions as defined in the subpattern filters of a rule in memory, groups eligible events, and
sends them to the phRuleMaster on a rule-by-rule and multithreaded basis. It uses a 30-second bucket for
this.

The phRuleMaster process queues up the data being received from the phRuleWorkers into buckets. It then
wakes up to evaluate all the rule data in parallel every 30 seconds, across multiple threads. The
phRuleMaster process is present on the supervisor only.

Advanced Analytics 6.3 Study Guide 185

 Rules

DO NOT REPRINT
© FORTINET

Scaling out the rule worker would require adding additional workers. The collectors will send events to the
workers, and the phRuleWorker process on an individual worker will forward those events in a summarized
form to the supervisor node, which also has a phRuleWorker. The task of phRuleWorker on the supervisor is
to summarize events that are sent from organizations directly to the supervisor node and assets that belong to
the super organization.

Advanced Analytics 6.3 Study Guide 186

 Rules

DO NOT REPRINT
© FORTINET

The phRuleWorkers feed summarizes data based on the event filter and group by conditions of the rule
subpattern conditions on a per-rule basis to the supervisor node. The summarized data is queued by the
supervisor node, waiting to be evaluated by the phRuleMaster.

Advanced Analytics 6.3 Study Guide 187

 Rules

DO NOT REPRINT
© FORTINET

The phRuleMaster wakes every 30 seconds to analyze the queue. It is the phRuleMaster that evaluates the
aggregation condition of a rule. If the aggregate conditions calculation matches the value defined in the rule,
then incidents will be generated.

Advanced Analytics 6.3 Study Guide 188

 Rules

DO NOT REPRINT
© FORTINET

The 30-second timer for phRuleMaster is the reason why the First Occurred or Last Occurred incident
timestamp is either on the minute, or 30 seconds past the minute on the incident dashboard.

Thirty seconds is an approximation because some rules may take longer to evaluate than others. Some are
looking for occurrences of a single event, some are looking for occurrences of many events, and some are
performing expensive calculations such as SUM across many thousands of matching events.

How much load is on the FortiSIEM is another factor. Every customer is different, and particular rules may or
may not be in play in other customer environments. Even though the rule evaluation is multithreaded, events
may spill across evaluation periods for complex rules.

Advanced Analytics 6.3 Study Guide 189

 Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about the sliding time window that the rule engine uses to evaluate events.

Advanced Analytics 6.3 Study Guide 190

 Rules

DO NOT REPRINT
© FORTINET

Two main dimensions of the rule engine time window are time and events. Events are evaluated over a period
of time and this general condition applies to the entire FortiSIEM. It’s all about time and matching events.
Time here does not refer to the timestamp of the event. It’s the time when FortiSIEM received the event.

Advanced Analytics 6.3 Study Guide 191

 Rules

DO NOT REPRINT
© FORTINET

Each rule on FortiSIEM has a specified time window and different values are used in the out-of-the-box rules.
This is the time window that the phRuleMaster will evaluate received data over, based upon the event receive
time. The minimum value for the time window is 120 seconds, with no defined maximum.

If you are creating your own rules, you must set the time window accordingly. You do not want the time
window to be too large or, by the time an incident is generated for your rule it might be too late. At the same
time, you should not make the time window too small because this will consume too much memory
unnecessarily.

Advanced Analytics 6.3 Study Guide 192

 Rules

DO NOT REPRINT
© FORTINET

Consider the matching events timeline for a single rule that has a 10-minute time window. The phRuleMaster
wakes up every 30 seconds to evaluate the last 10-minute time window for the rule.

Advanced Analytics 6.3 Study Guide 193

 Rules

DO NOT REPRINT
© FORTINET

New events are received during the non-evaluation time period. When the phRuleMaster wakes up after 30
seconds it will evaluate all the events that were received during the non-evaluation period. The events that are
outside the evaluation period, which have passed the evaluation sliding window, will not be considered in the
aggregation calculation by the phRuleMaster.

Advanced Analytics 6.3 Study Guide 194

 Rules

DO NOT REPRINT
© FORTINET

Every rule on FortiSIEM may have a different time window, which means that at any given time the
phRuleMaster is evaluating multiple rules all at the same time over various time windows. Some rules might
have a small time window and fewer events to process while other rules might have a large window and many
events to process. All these calculations and processing of events by the phRuleMaster is performed in the
memory, hence it can be very resource intensive.

Advanced Analytics 6.3 Study Guide 195

 Rules

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned about rules, including subpatterns in a rule
and the backend process that is involved in evaluating rules and triggering incidents. You also learned about
the sliding time window in a rule, out-of-box rules, and how each rule time window may be different.

Advanced Analytics 6.3 Study Guide 196

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the single subpattern security rule. You will also learn about incident
generation and the attributes that are involved in incident generation.

Advanced Analytics 6.3 Study Guide 197

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in the single subpattern security rule, you will be able to identify out-of-the-box
security rules, which are single subpattern, and understand how incidents are generated by those rules.

Advanced Analytics 6.3 Study Guide 198

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about event filters, group by, and aggregation conditions required in a single
subpattern rule.

Advanced Analytics 6.3 Study Guide 199

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

Single subpattern rules, as the name suggests, are constructed to evaluate a single condition that has
occurred in an environment. This could be login failures, high risk IPS events being received, or suspicious
commands being run at the command line, and more. These are the easiest rules to construct because, in
most cases, you are simply configuring FortiSIEM to count the number of occurrences of a particular event
being received during the time window.

Advanced Analytics 6.3 Study Guide 200

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This rule is an example of multiple VPN logon failures, which detects five consecutive failures in a 10-minute
period. This is an out-of-the-box rule that is active by default.

Advanced Analytics 6.3 Study Guide 201

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The ExcessVPNLogonFailure subpattern consists of Filters, Aggregate conditions, and Group By

definitions.

Advanced Analytics 6.3 Study Guide 202

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The subpattern filter determines which events the rule evaluates over the last 10-minute time window. It
gathers all received events that are part of the VPN Logon Failure CMDB group. In the example shown on
this slide, there are more than 100 different types of system-defined event definitions from various product
types, such as Cisco ASA, FortiGate, and so on.

You cannot modify the out-of-the-box event types, but you can create your own VPN logon failure event type
in the VPN Logon Failure CMDB group.

Advanced Analytics 6.3 Study Guide 203

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The Group By definition groups attributes from events that match the rule filter with exactly the same values.
In the example shown on this slide, if multiple VPN logon failure events have the same source IP, reporting
device, reporting IP, and user, they are grouped together in one row, and the count column tracks the number
of events for each of those rows.

The Aggregate condition determines a rule match when a resultant row from the query has five or more
matching events within the sliding 10-minute time window.

Advanced Analytics 6.3 Study Guide 204

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

In this section, you will walk through a single subpattern VPN logon failure.

Advanced Analytics 6.3 Study Guide 205

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

When someone enters incorrect credentials for a VPN logon, a logon failure event is sent to FortiSIEM. If the
number of logon failures within a specified time period is higher than the parameters configured in the rule, an
incident is triggered.

Advanced Analytics 6.3 Study Guide 206

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

To make the simulation easier to follow, the example shown on this slide uses a five-minute time window
instead of the actual 10-minute window. There are four users—Sarah, Ben, Mike, and Tracey—who are part
of the VPN user group.

The phRuleMaster wakes up at 15:05:00 to evaluate the events that have been queued. It evaluates all the
events related to VPN logon failures for the past five minutes. Ben and Mike had two logon failures and
Tracey had one logon failure. The group by definition is configured for source IP, reporting device, reporting
IP, and user. The aggregation count tracks the number of events against each row. In this evaluation period,
the count is less than five for the three users, therefore no incident is triggered and the phRuleMaster goes
back to sleep.

Advanced Analytics 6.3 Study Guide 207

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes. Any event outside the
evaluation time period is no longer under consideration.

The COUNT column is updated with two for Mike, one for Ben, and one for Tracey. The COUNT value for
each row is still less than five, therefore no incident is triggered and the phRuleMaster goes back to sleep.

Advanced Analytics 6.3 Study Guide 208

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

This time there is one failure event for Sarah, so a new row is added based on the group by condition, and the
COUNT column is updated with two for Mike, one for Ben, one for Tracey, and one for Sarah. The COUNT
value for each row is still less than five, so no incident is triggered and the phRuleMaster goes back to sleep.

Advanced Analytics 6.3 Study Guide 209

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with two for Mike, one for Ben, two for Tracey, and one for Sarah. The
COUNT value for each row is still less than five, so no incident is triggered and the phRuleMaster goes back
to sleep.

Advanced Analytics 6.3 Study Guide 210

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with two for Mike, two for Tracey, and one for Sarah. The row for Ben is
removed because it is not in the evaluation period. The COUNT value for each row is still less than five, so no
incident is triggered and the phRuleMaster goes back to sleep.

Advanced Analytics 6.3 Study Guide 211

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with two for Mike, two for Tracey, two for Sarah, and one for Ben. A new row
for Ben is added again because there is a new logon failure event within the new evaluation period. The
COUNT value for each row is still less than five, so no incident is triggered and the phRuleMaster goes back
to sleep.

Advanced Analytics 6.3 Study Guide 212

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with two for Mike, two for Tracey, two for Sarah, and one for Ben. The
COUNT value for each row is still less than five, therefore no incident is triggered and the phRuleMaster goes
back to sleep.

Advanced Analytics 6.3 Study Guide 213

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with one for Mike, two for Tracey, three for Sarah, and one for Ben. The
COUNT value for each row is still less than five, so no incident is triggered and the phRuleMaster goes back
to sleep.

Advanced Analytics 6.3 Study Guide 214

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with one for Mike, two for Tracey, four for Sarah, and one for Ben. The
COUNT value for each row is still less than five, so no incident is triggered and the phRuleMaster goes back
to sleep.

Advanced Analytics 6.3 Study Guide 215

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with one for Tracey, four for Sarah, and one for Ben. The row for Mike is
removed because it is not in the evaluation period. The COUNT value for each row is still less than five, so no
incident is triggered and the phRuleMaster goes back to sleep.

Advanced Analytics 6.3 Study Guide 216

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

After 30 seconds, the phRuleMaster wakes up again to evaluate the events that have been queued. It again
evaluates all the events related to VPN logon failures for the past five minutes.

The COUNT column is updated with five for Sarah, one for Tracey, and one for Ben. This time there is a
match for Sarah because of the five failed logon attempts.

Advanced Analytics 6.3 Study Guide 217

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The matching group by and aggregation parameters are the only fields that you can use as inputs to take
action.

Advanced Analytics 6.3 Study Guide 218

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

Once the incident parameters are determined, you must configure an Action, along with the Severity,
Category, and Subcategory of the resulting incident.

Advanced Analytics 6.3 Study Guide 219

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about incident attributes, severity, and category.

Advanced Analytics 6.3 Study Guide 220

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The incident dashboard displays incident information for your IT infrastructure based on the filter conditions
you configure. You can also view incidents grouped by incident attributes, use values in incident attributes to
refine your searches, view information about rules that triggered incidents, and use incident information to
create rule exceptions and event dropping rules.

Advanced Analytics 6.3 Study Guide 221

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

When you configure a rule, you can define the action that must be taken when the rule matches the aggregate
conditions. Before you define an action, you must specify the severity, category, and subcategory for the
incident. Severity is rated 1-10, where 1-4 is low, 5-8 is medium, 9-10 is high. The category determines the
type of incident that is being reported, which is useful for filtering on the incident dashboard. The subcategory
allows a further categorization of the incident.

Advanced Analytics 6.3 Study Guide 222

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

In the Technique drop-down list, select a technique that describes the incident that the rule created. The
tactic is automatically populated based on the selected technique.

Advanced Analytics 6.3 Study Guide 223

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

When you edit the Action field, the only fields that you can select are from the matching subpattern aggregate
and group by conditions. Most often for out-of-the-box rules, the event attribute is the filter attribute, but the
two are different.

In the example shown on this slide, the reporting device is the destination host name and the reporting IP is
the destination IP because the firewall that is reporting the events to FortiSIEM is actually the device where
the VPN terminates, so it is considered the final destination.

Advanced Analytics 6.3 Study Guide 224

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

You can customize the default incident title by adding attribute variables related to the incident, strings,
numbers, and characters. You should precede each attribute variable that you type in the incident title with a
$. When the incident is generated, the title of the incident has the value associated with the attribute variable
that you specified in the incident title.

Advanced Analytics 6.3 Study Guide 225

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

When an incident triggers, a new event is actually generated in the back end, which is not visible by default.
The name of the incident is determined by the rule name, and the description of the incident is also borrowed
from the description in the rule.

Advanced Analytics 6.3 Study Guide 226

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This slide shows another incident example—Multiple Logon Failures: VPN. The Source, Target, and Detail
columns show a single line summary of the incident, which is automatically determined by FortiSIEM by
analyzing the incident attributes that you defined in the rule.

What was considered the source of the attack and the target in your environment against which the attack
was made, and any other quick supporting details, are populated by extracting the information from the
events. Additionally, other incident attributes that have been generated that are not related to the source or
target are collated under the Detail section of the incident. This information is important for notification policies
and, especially, remediation actions.

Advanced Analytics 6.3 Study Guide 227

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The incident source attributes shown on this slide are hardcoded on FortiSIEM. These attributes will appear
under the incident source field on the Incident tab. The most common source attributes are source IP and
source user.

Advanced Analytics 6.3 Study Guide 228

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

The incident target attributes shown on this slide are hardcoded on FortiSIEM. These attributes will appear
under the incident Target field on the Incident tab. The most common target attributes are destination IP,
destination host name, host IP, and host name.

Advanced Analytics 6.3 Study Guide 229

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This slide shows a few more examples of incident target attributes. Note that the reporting IP and reporting
device are not incident target fields. So, if you have the reporting IP or reporting device as filter attributes
while defining incident attributes, you must select a different event attribute.

Advanced Analytics 6.3 Study Guide 230

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This is one of the special cases where User and Target User are both incident target fields by default. If a list
of incident attributes contains both User and Target User, the user attribute is placed in the incident source
field.

Advanced Analytics 6.3 Study Guide 231

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

To differentiate between the user and target user, think about a login to the network or a device. There is only
one field in the log message related to which user tried to log on. Now, think about an administrative change
to a user account in Active Directory—maybe an account was disabled. The log contains two user-related
fields—the one who made the change, and whose account was modified. In this case, FortiSIEM parses the
account that was changed to be the target user, and who made the change as the user.

Advanced Analytics 6.3 Study Guide 232

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

Take a look at the incident attributes for the Multiple Logon Failures: VPN rule shown on this slide.

The incident Source is the Source IP event attribute.

The incident Target is the Reporting IP, Reporting Device, and User attributes.

Any other event attributes, in this case Triggered Event Count, are displayed in the incident Detail.

Advanced Analytics 6.3 Study Guide 233

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

When you click the Events tab in the incident, you can see the attributes that will appear for matching events
for that incident. These are the attributes you selected in the rule when you configured the action. Event Type
displays Event Name and provides an option for Event Type called Show Event Type.

Advanced Analytics 6.3 Study Guide 234

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This slide summarizes the multiple VPN logon failures incident. The incident name comes from the rule name.
The Incident Attributes populates the incident Source, Target, and Detail information. The Triggered
Attributes determine the fields to show in the matching events that triggered the incident. By default the
incident name is the name of the rule that triggered that incident, but that can be overwritten by configuring a
name for the incident through the Incident Title field on the rule.

Advanced Analytics 6.3 Study Guide 235

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

This slide lists some single rule pattern best practices.

The subpattern aggregation contains either a matched event count or distinct attribute count. Remember that
you must define the group by attributes that you want to see present in the incident source, target, or detail.
Aggregations, such as matched event counts, distinct attribute counts, average, sum, and so on, calculate
single values and can also be present in the incident detail.

Consider how many matching events occur when defining the rule time window, because these events are
stored in memory.

Advanced Analytics 6.3 Study Guide 236

 Single Subpattern Security Rules

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned about the single subpattern security rule. You
also learned about incident generation and the attributes that are involved in incident generation.

Advanced Analytics 6.3 Study Guide 237

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about multiple subpattern rules, and the procedure to construct a multiple
subpattern rule.

Advanced Analytics 6.3 Study Guide 238

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in identifying multiple subpattern rules, you will be able to define conditions
and take action in a multipattern rule.

Advanced Analytics 6.3 Study Guide 239

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about event filters, group by, and aggregation conditions required in a multiple
subpattern rule.

Advanced Analytics 6.3 Study Guide 240

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

FortiSIEM supports rules with multiple subpatterns. These cover conditions where two patterns may need to
occur within a specific time period, or one of a selection of patterns needs to occur to prove an incident
condition exists. If multiple patterns are used, then just like the analytics, you must specify a next operator.
FortiSIEM supports five types of next operators, shown on this slide.

Advanced Analytics 6.3 Study Guide 241

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

This slide highlights some out-of-the-box rules that have multiple conditions.

Advanced Analytics 6.3 Study Guide 242

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

This slide shows the Excessive End User DNS Queries rule, which detects a scenario where a host that is not
a DNS server, is sending excessive DNS requests. Authorized DNS servers are represented by the DNS
server group. In a typical scenario, the frequency of end host DNS requests is not high unless there is a script
running. This might indicate the presence of malware on the end host.

Advanced Analytics 6.3 Study Guide 243

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

Successful Account Activity on a Disabled Account is a built-in rule that tracks user account login activity for a
user whose account has recently been disabled by the administrator.

Advanced Analytics 6.3 Study Guide 244

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The rule contains two subpatterns—AcctDisabled and SuccessLogin—with a FOLLOWED_BY operator.

The rule is tracked over a much larger time window of 86400 seconds, which is 24 hours.

Advanced Analytics 6.3 Study Guide 245

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The AcctDisabled subpattern tracks Windows security events that have the IDs 629 and 4725, which relate
to user accounts being disabled.

After the events are grouped by Reporting Device, Reporting IP, and Target User, if one or more events
match the aggregate condition then the subpattern is considered a match.

Advanced Analytics 6.3 Study Guide 246

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The second subpattern in the rule is SuccessLogin, which tracks successful login event types from the Dev
Logon Success and Domain Logon Success CMDB groups.

After the events are grouped by Source IP, Computer, Reporting IP, and User, if one or more events match
the aggregate condition then the subpattern is considered a match.

Advanced Analytics 6.3 Study Guide 247

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

There are 139 different types of out-of-the-box device login success rules, and 10 types of domain login
success rules. You can create your own event types under any category and reference them in a rule
subpattern.

Advanced Analytics 6.3 Study Guide 248

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The phRuleMaster still wakes every 30 seconds to evaluate the queue. For visualization purposes, this lesson
concentrates on a 24-hour block of time.

Advanced Analytics 6.3 Study Guide 249

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

Under normal operation, you would expect lots of successful login events within a 24-hour time period, along
with some odd account disabled events.

What would be unusual is an account being disabled then, a short time later, the same account being used for
a successful login.

Advanced Analytics 6.3 Study Guide 250

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

When there are multiple subpatterns, you may need to define a relationship between those subpatterns. In the
example shown on this slide, the Target User in the AcctDisabled subpattern must be equal to the user in
the SuccessLogin subpattern. Also, the Reporting IP in the AcctDisabled subpattern must be equal to the
Reporting IP in the SuccessLogin subpattern.

If you do not define this relationship, FortiSIEM can generate false positive incidents. By defining this
relationship, you are making a condition where the user who was actually disabled by the administrator is the
same user who logged in successfully at a later time. Also, the same device that reported a disabled account
event is also reporting the successful login event.

On the back end, you can also use the event receive time to identify the order in which the events were
received. This is how FortiSIEM knows if the disabled account event occurred before the successful event.

Advanced Analytics 6.3 Study Guide 251

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

This slide shows two tables—one for the AcctDisabled subpattern and the other for the SuccessLogin
subpattern. The columns in the table are named according to the group by definition for each subpattern. The
group by definition for the AcctDisabled subpattern is reporting device, reporting IP, and target user. The
group by definition for the SuccessLogin subpattern is source IP, computer, reporting IP, and user.

The phRuleMaster evaluates the events for a 24-hour period. The AcctDisabled subpattern tracked two
events in which the administrator had disabled the user accounts for Chris and Bryan. The SuccessLogin
subpattern tracked one event for Dan, who had logged in successfully. The rule compares the disabled
account for Chris and the successful login event for Dan. FortiSIEM goes through the analysis of the events
and decides if it should trigger an incident:
• Was the AcctDisabled event earlier than the SuccessLogin event? The answer is yes.
• Is the reporting IP of the AcctDisabled event the same as the reporting IP of the SuccessLogin event? The
answer is yes.
• Is the target user of the AcctDisabled event the same as the user of the SuccessLogin event? The answer
is no.

Therefore, no incident is triggered.

Now, the rule compares Bryan’s disabled user account with the successful login event for Dan:
Was the AcctDisabled event earlier than the SuccessLogin event? The answer is no.

At this point, the rule does not need to process the rule relationship condition because the disabled login event
was received after the successful login event. During this evaluation window, no incident is triggered because
the only user who logged in successfully is Dan, and his account was not disabled by the administrator.

Advanced Analytics 6.3 Study Guide 252

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

Now, the rule compares the disabled user account for Bryan and the successful login event for Dan:
Was the AcctDisabled event earlier than the SuccessLogin event? The answer is no.

At this point, the rule does not need to process the rule relationship condition because the disabled login event
was received after the successful login event. During this evaluation window, no incident is triggered because
the only user who logged in successfully is Dan, and his account was not disabled by the administrator.

Advanced Analytics 6.3 Study Guide 253

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

Now, fast forward to 13:30, when more events have been received. Users Wendy and Bryan had logged in
successfully since the last evaluation.

The rule compares Chris’ disabled user account and the successful login event for Dan. No incident is
triggered because the target user from the AcctDisabled event is not the same as the user from the
SuccessLogin event.

Advanced Analytics 6.3 Study Guide 254

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The rule compares the disabled user account for Chris and the successful login event for Wendy. No incident
is triggered because the target user from the AcctDisabled event is not the same as the user from the
SuccessLogin event.

Advanced Analytics 6.3 Study Guide 255

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The rule compares the disabled user account for Chris and the successful login event for Bryan. No incident is
triggered because the target user from the AcctDisabled event is not same as the user from the SuccessLogin
event.

Advanced Analytics 6.3 Study Guide 256

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The rule compares the disabled user account for Bryan and the successful login event for Dan. No incident is
triggered because the AcctDisabled event occurred earlier than the SuccessLogin event.

Advanced Analytics 6.3 Study Guide 257

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

The rule compares the disabled account for Bryan and the successful login event for Wendy. No incident is
triggered because the target user from the AcctDisabled event is not the same as the user from the
SuccessLogin event.

Advanced Analytics 6.3 Study Guide 258

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

Finally, the rule compares the disabled user account for Bryan and the successful login event for Bryan. An
incident is triggered because Bryan logged in after his account was disabled. It is the same device that
reported Bryan’s disabled account event and his successful login event.

Advanced Analytics 6.3 Study Guide 259

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

You can select the incident attributes from either subpattern or both. Each matching event returns the same
attributes on the Incident tab for each subpattern. Therefore, some fields may be empty. You can customize
the incident title by inserting attributes from the Insert Attributes drop-down list.

Advanced Analytics 6.3 Study Guide 260

 Multiple Subpattern Rules

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to deploy FortiSIEM and collect logs with
FortiSEIM without a collector.

Advanced Analytics 6.3 Study Guide 261

 Baselines

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about baselines on FortiSIEM and analyze the backend profile report that is
responsible for tracking baseline data.

Advanced Analytics 6.3 Study Guide 262

 Baselines

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in baselines, you will be able to understand the mathematics involved in
calculating statistical values for various data from various devices and event types.

Advanced Analytics 6.3 Study Guide 263

 Baselines

DO NOT REPRINT
© FORTINET

In this section, you will learn about the baseline process and examine a few use case examples.

Advanced Analytics 6.3 Study Guide 264

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM has many rules that track specific thresholds and utilization values, such as disk space, CPU and
memory utilization, failed logins, and more. These values are either fixed, such as five or more failed logins,
system defaults, such as 95% CPU utilization, or user-defined override values specifying different thresholds
per CMDB device or object. Changing these static hard-coded thresholds requires manual tuning of the
system and can be a tedious process.

Advanced Analytics 6.3 Study Guide 265

 Baselines

DO NOT REPRINT
© FORTINET

When FortiSIEM is configured and running, it receives and collects events from which it can learn over time
what is considered normal activity and thresholds, by modeling the data and creating baselines.

This requires an initial collection of baseline data, which is the learning phase. This baseline data serves as a
basis for comparison with the subsequently acquired data. If the system understands the past performance of
a user, device, or traffic profile, then by constantly monitoring in real-time the present behavior, alerts can be
generated when these values deviate from the norm, so you can identify what is not normal.

FortiSIEM will constantly learn from past behavior and these baselines will constantly evolve.

Advanced Analytics 6.3 Study Guide 266

 Baselines

DO NOT REPRINT
© FORTINET

This is an example of a baseline profile for sudden increases in CPU utilization that may be outside the
normal behavior. In this case, the CPU utilization spikes above the baseline value, which is considered an
abnormal behavior by the baseline profile.

Advanced Analytics 6.3 Study Guide 267

 Baselines

DO NOT REPRINT
© FORTINET

A sudden decrease could also indicate an issue. The baseline profile also tracks for data that is below the
baseline average value.

Advanced Analytics 6.3 Study Guide 268

 Baselines

DO NOT REPRINT
© FORTINET

These are few of the scenarios that would be applicable for a baseline profile.

If there is a brute force attack, then most likely there is increased failed user logins. If the traffic profile for a
particular user is different on a specific day compared to what it usually is, then it is considered an insider
threat. If there is an unusual spike in user latency then most likely it could be a server outage.

If FortiSIEM detects an increase in a rare event from a device, then it is mostly likely a device or a component
failure. If the incoming event rate from a device suddenly increases, then it could indicate a configuration
issue on the device. If there is an increase in firewall connections or server processes are launched, then it
could indicate a virus or worm outbreak.

Advanced Analytics 6.3 Study Guide 269

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM uses two small dedicated SQLite databases used for the baseline data—profile database and daily
database. These databases are located on disk 1 of the supervisor node. The databases will store running
trends of learned baseline data calculated for many parameters, such as traffic and device resource usage
profiles, running averages, and standard deviation values.

Advanced Analytics 6.3 Study Guide 270

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM recognizes that device and user resource usage is time dependent. This means that usage is
different during weekdays and weekends. For example, internal websites will be accessed more frequently
during a weekday than during weekends, and hosts should produce fewer DNS requests during the weekend.
Also, the usage is different depending upon the hour of the day. During business hours there will naturally be
more traffic. You can expect more failed logins when the users first log in in the morning on business days. To
take various scenarios into consideration, FortiSIEM builds distinct baselines for hours of the weekdays and
weekends.

Advanced Analytics 6.3 Study Guide 271

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM uses hourly buckets to store data for specific baseline profiles. Each baseline report has a set of
keys that represents the baselined metrics and a collection of resultant values. The supervisor and any worker
nodes operate in parallel to analyze the previous hour’s data for each baseline, with the supervisor
summarizing the results and storing the data in the SQLite database.

The term used is hour of day for the hour that is being analyzed. When FortiSIEM collects data between 1
p.m. to 1:59:59 p.m., that data will be analyzed at 2 p.m. and that will be for the 1 p.m. hour of day. This
process is done for each hour of the day as new baselines values are learned.

Advanced Analytics 6.3 Study Guide 272

 Baselines

DO NOT REPRINT
© FORTINET

Baselines are recorded for each hour of the day during a weekday and weekend, with a total of 48 buckets.
Each weekday hourly bucket is recycled the next day, which means Tuesday 1 p.m. replaces the 1 p.m. value
from Monday. Similarly, each weekend hourly bucket is recycled the next weekend, which means Saturday 1
p.m. is replaced by Sunday 1 p.m. and so on.

Advanced Analytics 6.3 Study Guide 273

 Baselines

DO NOT REPRINT
© FORTINET

When you navigate to baseline reports, you can view the out-of-the-box baseline reports. You can create your
own baseline report from here.

Do not confuse this with the baseline profile, which can be created only in the backend.

Advanced Analytics 6.3 Study Guide 274

 Baselines

DO NOT REPRINT
© FORTINET

Current baseline data can be returned and filtered for each hour of the day, by running a baseline report. This
data is queried from the profile database for each hour.

Advanced Analytics 6.3 Study Guide 275

 Baselines

DO NOT REPRINT
© FORTINET

The baseline data can be used by the rule engine to evaluate aggregate conditions in a rule. The rule engine
loads the baseline values for each hour from the profile database into the memory and then computes the
aggregate condition against the current data. If the result points to an anomaly from the baseline values, then
the rule can trigger an incident.

Advanced Analytics 6.3 Study Guide 276

 Baselines

DO NOT REPRINT
© FORTINET

There are several out-of-the-box rules that refer to baseline data to compute aggregate conditions and
generate incidents. The rule names start with the term Sudden.

Advanced Analytics 6.3 Study Guide 277

 Baselines

DO NOT REPRINT
© FORTINET

In this section, you will learn the theory behind baselines on FortiSIEM.

Advanced Analytics 6.3 Study Guide 278

 Baselines

DO NOT REPRINT
© FORTINET

A profile report is defined to collect relevant data, such as the number of failed logons on an hourly basis. This
is the data you want to baseline. This data is written to the daily database on an hourly basis.

At midnight, this data is processed and written to the profile database, and the daily database is emptied.
When baseline reports are run from the GUI, FortiSIEM uses the data from the profile database and not from
the event database like other reports.

Advanced Analytics 6.3 Study Guide 279

 Baselines

DO NOT REPRINT
© FORTINET

Just like a normal report template, a baseline profile report contains the search filter, aggregations, and
ordering conditions to generate the results that the baseline will learn. The profile report is the XML definition
of the report, because the profile report can be configured only from the backend. Many profiles are
preconfigured out-of-the-box and it is possible to create your own. The syntax for the profile report is slightly
different from a standard report template, because it contains the reference to a profile ID and profile event
type.

Advanced Analytics 6.3 Study Guide 280

 Baselines

DO NOT REPRINT
© FORTINET

This slide shows the XML definition of a baseline report. This should not be confused with a baseline profile.
You can select and export a baseline report in XML format. All the attributes that you see in the XML file can
be defined through the GUI.

Advanced Analytics 6.3 Study Guide 281

 Baselines

DO NOT REPRINT
© FORTINET

The profile reports are defined in the ProfileReports.xml file in the FortiSIEM backend. This slide shows
an example of the failed logon profile, which has an unique identifier—122. The profile event type defines the
way the data from this profile will be referenced in the baseline reports and rules. The profile also defines the
number of rows to store in the SQLite database for this profile. You must assign a name to the profile, which
does not appear in the GUI. It is defined for the purpose of identifying the profile. You must also define the
events that will be evaluated by this profile, and define how the results will be grouped.

Advanced Analytics 6.3 Study Guide 282

 Baselines

DO NOT REPRINT
© FORTINET

For the baseline profile to perform aggregation, you must first group the results, which are defined along with
the aggregate function.

In the example shown on this slide, the results will be grouped by reporting device name and reporting device
IP address. After the results are grouped into those two columns, three more columns will be added for the
count functions, which are the aggregate function. After that, the results will be arranged in descending order
according to the count column value.

The window specifies how often the baseline profile will collect data points and over what time period. In this
example, the data will be collected every hour for 24 hours. This means that the baseline profile will consider
all failed logon events for an hour and perform the necessary calculations and then store that result in the
daily database bucket.

Advanced Analytics 6.3 Study Guide 283

 Baselines

DO NOT REPRINT
© FORTINET

The profile event types are mappings between the SQLite databases and the statistically calculated baseline
results. PH_PROF event types contain a reference to a particular SQLite profile ID, which relates to a profile
table within SQLite. There is one unique profile ID and profile event type per baseline.

The number of rows determines how much data to keep and baseline for each profile. Typically, the size of
the profile database is less than 64 MB, but could be as high as 500 MB in the multitenant edition. In the
enterprise edition, the data always belongs to the same customer. In the multitenant edition, this value is split
among customers. For example, if an MSSP has 10 customers and 5000 rows, then each customer will get
500 rows.

Advanced Analytics 6.3 Study Guide 284

 Baselines

DO NOT REPRINT
© FORTINET

The SQLite databases on the supervisor node are located in the cache directory. The specific directory paths
are shown on this slide.

Each profile has its own table in each database. The number in the PH_PROF event type relates to a specific
profile table. In the case of the failed logon profile it is profile_122.

Advanced Analytics 6.3 Study Guide 285

 Baselines

DO NOT REPRINT
© FORTINET

In this section, you will learn about the failed logon profile in depth.

Advanced Analytics 6.3 Study Guide 286

 Baselines

DO NOT REPRINT
© FORTINET

This is the XML definition of the failed user logon profile report that you have seen on previous slides. You will
analyze the report output and correlate that data with SQLite database attributes. The report will display seven
columns and order them in ascending order based on profile date type and hour of day. It will also order them
in descending order based on average matched events.

Advanced Analytics 6.3 Study Guide 287

 Baselines

DO NOT REPRINT
© FORTINET

When you edit the report, you will notice that a special flag called Anomaly Detection Baseline is set to
distinguish this report from regular reports. The PH_PROF event type determines which profile will be read in
the SQLite database—in this case it is the failed logon profile with ID 122.

Advanced Analytics 6.3 Study Guide 288

 Baselines

DO NOT REPRINT
© FORTINET

The display column of the baseline report returns the selected SQLite database columns from profile 122.
Profile date type, hour of day, reporting device, and reporting IP are the group by attributes. Average matched
events, average distinct user, and average distinct source IP are the aggregate functions.

Advanced Analytics 6.3 Study Guide 289

 Baselines

DO NOT REPRINT
© FORTINET

When you run the baseline report, FortiSIEM will query the profile database and display the results, which
contains the group by fields column and the aggregate fields column.

Advanced Analytics 6.3 Study Guide 290

 Baselines

DO NOT REPRINT
© FORTINET

This slide compares various aggregate conditions and their equivalent terms in the SQLite profile table.

Advanced Analytics 6.3 Study Guide 291

 Baselines

DO NOT REPRINT
© FORTINET

In this section, you will learn about calculating MIN, MAX, AVG, and STD DEV.

Advanced Analytics 6.3 Study Guide 292

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM creates and then constantly updates the learned baseline with time series data.

The average, or arithmetic mean, refers to the sum of the numbers in a set divided by how many numbers are
being averaged. The variance is defined as the average of the squared differences from the mean.

The standard deviation (σ) is the square root of the variance, which is basically a measure of the variation of a
set of data values from its mean.

Advanced Analytics 6.3 Study Guide 293

 Baselines

DO NOT REPRINT
© FORTINET

Consider the example shown on this slide, where a single host is being monitored for CPU utilization. Every 3
minutes the CPU utilization metrics are collected. To simplify the demonstration, assume that only a single
sample is collected every 3 minutes.

Advanced Analytics 6.3 Study Guide 294

 Baselines

DO NOT REPRINT
© FORTINET

First, the mean value will be calculated over an evaluation window. Over an evaluation window, many
samples are collected. FortiSIEM uses an hour for evaluating samples, but a 30-minute window will be used
for demonstrating the calculations.

Advanced Analytics 6.3 Study Guide 295

 Baselines

DO NOT REPRINT
© FORTINET

The mean is the sum of polling sample values divided by the number of values. In the example shown on this
slide, there are ten samples with distinct CPU utilization values. When you add the values from each of these
samples and divide by the number of samples, then you will get the mean value of 32.3.

Advanced Analytics 6.3 Study Guide 296

 Baselines

DO NOT REPRINT
© FORTINET

Variance is the average of the the squared differences from the mean. In order to calculate variance, you
need to first calculate the variation of each sample from the mean value. If the CPU utilization is higher than
the mean value, then it will be a positive difference. If the CPU utilization is below the mean value, then it will
be a negative difference. You square all the difference values and add them. The sum is divided by the
number of samples, which in this case is 10. The final result is the variance value.

Advanced Analytics 6.3 Study Guide 297

 Baselines

DO NOT REPRINT
© FORTINET

Standard deviation is the square root of the variance value.

Advanced Analytics 6.3 Study Guide 298

 Baselines

DO NOT REPRINT
© FORTINET

Once you determine the standard deviation, you can determine the positive and negative deviation from the
mean value. To determine the first positive deviation, you need to add the deviation value to the mean value.
To determine the first negative deviation, you need to subtract the deviation from the mean value. You will
notice that four samples are outside the first deviation.

Advanced Analytics 6.3 Study Guide 299

 Baselines

DO NOT REPRINT
© FORTINET

You can determine the second and third deviation by multiplying the standard deviation by two and three
respectively, and then calculating the positive and negative deviation from the mean by adding or subtracting
that value from the mean.

Advanced Analytics 6.3 Study Guide 300

 Baselines

DO NOT REPRINT
© FORTINET

Since FortiSIEM uses hourly buckets, values are recorded for each profile every hour. In the backend,
FortiSIEM calculates the minimum, maximum, average, and standard deviation for attributes that are related
to each profile and stores those in buckets every hour. Hence, there are 24 buckets for a weekday, and 24
buckets for weekends; one per hour. Since there is only one data point, the results are real values.

Advanced Analytics 6.3 Study Guide 301

 Baselines

DO NOT REPRINT
© FORTINET

This is an example of the CPU utilization that is reported by a server on the first day. Every value that is
reported for every hour of the day is considered a real value. Hence the minimum, maximum, and average will
be the same value since there is no comparison with any other values against the daily database.

The standard deviation will be zero since there is no secondary data to compare the deviation for every hour.
The numPoints column will update each hour of day with 1 since there is only one value in the database for
that hour.

Advanced Analytics 6.3 Study Guide 302

 Baselines

DO NOT REPRINT
© FORTINET

At midnight on the first day, the daily database values are populated into the profile database, and the daily
database is purged to make ready for the next day’s values. After the first day, the values in the profile
database will be the same as the values in the daily database. There is no processing of data since there is
only one data point for each hour.

Advanced Analytics 6.3 Study Guide 303

 Baselines

DO NOT REPRINT
© FORTINET

You might think that the average is just the real average value, but that’s not true. FortiSIEM uses a statistical
weighted average for all future points, since FortiSIEM does not store all previous values. A weighted average
is an average that has a multiplying factor. It is calculated by using an alpha weight, where a percentage of
the old average value is added to a percentage of the new real average value. The standard deviation and
variance are also calculated using the weighted values. This is a proprietary algorithm and the values cannot
be changed.

Advanced Analytics 6.3 Study Guide 304

 Baselines

DO NOT REPRINT
© FORTINET

On the second day, the daily database is again populated with real data values. On this slide, the data values
for the previous day are shown for reference only.

Since the daily database has been emptied at midnight, it does not have the data values for the previous day.
It will populate the minimum, maximum, average, and standard deviation as if it is receiving this data for the
first time. So the minimum, maximum, and average will be the same value with standard deviation as 0. The
numPoints column will be updated again with 1.

Advanced Analytics 6.3 Study Guide 305

 Baselines

DO NOT REPRINT
© FORTINET

At midnight on the second day, FortiSIEM will need to perform some calculations before storing those values
in the profile database. It will update the minimum and maximum values for every hour of the day by
comparing the values stored in the profile database for day one and those values that are currently in the daily
database of the second day. It will also calculate the new weighted average and standard deviation values.
After performing those calculations, it will store those values in the profile database and update the numPoints
field in the profile database to 2. This means that the data stored is based on two data points for every hour. In
this way FortiSIEM is constantly learning and creating new baselines in the profile database. The daily
database will be emptied for the third day.

Advanced Analytics 6.3 Study Guide 306

 Baselines

DO NOT REPRINT
© FORTINET

Now, you will analyze the calculation that is performed in the backend by FortiSIEM for hour 9 at midnight.

The daily database contains the new CPU utilization data for day two, which is 33.50. The profile database
has the data for the same hour from the previous day, which is 32.31. The weighted average between day one
and day two is 32.67. FortiSIEM compares the minimum and maximum value between the daily database and
the profile database. It concludes that the minimum value does not need to be changed and it will keep that
value as 32.31. The profile database which contains the previous values for hour 9, will be updated with the
new learned baseline.

Advanced Analytics 6.3 Study Guide 307

 Baselines

DO NOT REPRINT
© FORTINET

The maximum CPU utilization value for hour 9 needs to be updated in the profile database. It will update the
maximum value in the profile database for hour 9 to 33.50. It will also update the average CPU utilization
value for that hour to 32.67. The numPoints column will be updated to 2 because the calculation is based on
two data points. It will then calculate the standard deviation between those two data points and update that to
0.55. That will be the new baseline for hour 9.

Advanced Analytics 6.3 Study Guide 308

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM will perform similar calculation for hour 10. The daily database contains the new CPU utilization
data for day two, which is 37.06. The profile database has the data for the same hour from the previous day,
which is 32.52. The weighted average between day one and day two is 33.88. FortiSIEM compares the
minimum and maximum value between the daily database and the profile database. It concludes that the
minimum value does not need to be changed and it will keep that value as 32.52.

Advanced Analytics 6.3 Study Guide 309

 Baselines

DO NOT REPRINT
© FORTINET

The maximum CPU utilization value for hour 10 needs to be updated in the profile database. It will update the
maximum value in the profile database for hour 10 to 33.88. It will also update the average CPU utilization
value for that hour to 37.06. The numPoints column will be updated to 2 because the calculation is based on
two data points. It will then calculate the standard deviation between those two data points and update that to
2.08. That will be the new baseline for hour 10.

Advanced Analytics 6.3 Study Guide 310

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM will perform similar calculations for hour 11. The daily database contains the new CPU utilization
data for day two, which is 40.12. The profile database has the data for the same hour from the previous day,
which is 45.10. The weighted average between day one and day two is 43.61. FortiSIEM compares the
minimum and maximum value between the daily database and the profile database. It concludes that the
maximum value does not need to be changed and it will keep that value as 45.10.

Advanced Analytics 6.3 Study Guide 311

 Baselines

DO NOT REPRINT
© FORTINET

The minimum CPU utilization value for hour 11 needs to be updated in the profile database. It will update the
minimum value in the profile database for hour 11 to 40.12. It will also update the average CPU utilization
value for that hour to 43.61. The numPoints column will be updated to 2 because the calculation is based on
two data points. It will then calculate the standard deviation between those two data points and update that to
2.28. That will be the new baseline for hour 11.

Advanced Analytics 6.3 Study Guide 312

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM will perform similar calculations for hour 12. The daily database contains the new CPU utilization
data for day two, which is 43.61. The profile database has the data for the same hour from the previous day,
which is 45.96. The weighted average between day one and day two is 44.32. FortiSIEM compares the
minimum and maximum value between the daily database and the profile database. It concludes that the
minimum value does not need to be changed and it will keep that value as 43.61.

Advanced Analytics 6.3 Study Guide 313

 Baselines

DO NOT REPRINT
© FORTINET

The maximum CPU utilization value for hour 12 needs to be updated in the profile database. It will update the
maximum value in the profile database for hour 12 to 45.96. It will also update the average CPU utilization
value for that hour to 44.32. The numPoints column will be updated to 2 because the calculation is based on
two data points. It will then calculate the standard deviation between those two data points and update that to
1.08. That will be the new baseline for hour 12.

Advanced Analytics 6.3 Study Guide 314

 Baselines

DO NOT REPRINT
© FORTINET

FortiSIEM is constantly learning new baselines every day. For weekdays, the data from Tuesday overwrites
the data from Monday, and so on. For weekends, the data from Sunday overwrites the data from Saturday.

Advanced Analytics 6.3 Study Guide 315

 Baselines

DO NOT REPRINT
© FORTINET

You can view the baseline data from the profile database for individual profiles by running the baseline profile
report. You can view the current baseline of minimum, maximum, average, and standard deviation values for
individual profiles.

Advanced Analytics 6.3 Study Guide 316

 Baselines

DO NOT REPRINT
© FORTINET

To create your own baseline profile, you have to identify an unused profile ID that you can use. Define your
new profile event type on the FortiSIEM GUI, and then create your profile report on the FortiSIEM backend
and insert it into the ProfileReports.xml file.

The profile report is always looking at aggregated data, and must contain an order by definition.

Finally, restart phReportWorker and phReportMaster, and define any new attributes that are used for
min, max, average, and standard deviation in SQLite.

Advanced Analytics 6.3 Study Guide 317

 Baselines

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to understand baselines on FortiSIEM
and analyze the backend profile report that is
responsible for tracking baseline data.

Advanced Analytics 6.3 Study Guide 318

 Baseline Rules

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about baseline rules and how they can evaluate aggregate functions by querying
data from the baseline profile.

Advanced Analytics 6.3 Study Guide 319

 Baseline Rules

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding baseline data and Z-score, you will be able to analyze out-of-
the-box baseline rules, and create your own baseline rules with statistical expressions.

Advanced Analytics 6.3 Study Guide 320

 Baseline Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about baseline data and the type of data that is fetched from the profile database
by the rule engine.

Advanced Analytics 6.3 Study Guide 321

 Baseline Rules

DO NOT REPRINT
© FORTINET

Once baseline data is populated in the profile database, the rule engine can query the statistical average or
standard deviation values from any profile in the database. The rule engine can query the current hour of the
day from a weekday or from a weekend and load that value into memory. After it loads, the statistical value
into memory, the engine compares that value against the current rule aggregations, such as count, sum,
average, and so on. Based on that comparison, the rule may or may not trigger an incident.

The value, once cached, stays in the memory for that hour. If the rule needs to process more events during
that hour, then it will use the value that is already cached. If, for some reason, the cached value is lost, then it
retrieves them from the SQLite database and caches them for future use during the hour.

Advanced Analytics 6.3 Study Guide 322

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows an example of a sudden increase in CPU utilization on a server.

The rule engine will query the profile database every hour for the statistical average and standard deviation
values for that hour. The values from the profile database are cached by the rule engine. FortiSIEM then
keeps monitoring the server, and periodically compares the actual CPU utilization against the statistical
average and statistical standard deviation value that was cached in the memory from the profile database. If
the calculations return a value that indicates an anomaly, then an incident is triggered.

Advanced Analytics 6.3 Study Guide 323

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows a few examples of the out-of-the-box system resource baseline rules.

The Sudden Increase in System CPU Usage rule queries profile ID 109. It detects the increase in CPU usage
by calculating the current average over a 30-minute interval. The rule triggers when this value is more than 3
standard deviations away from the mean and the current average is at least 50 percent.

The Sudden Increase in System Memory Usage rule queries profile ID 109. It detects the increase in system
memory usage over a 30-minute interval. This rule triggers when either the physical or virtual memory usage
is 25% more than the statistical average over that same time period and the current physical memory usage is
at least 50%.

The Sudden Increase in Ping Response Times rule queries profile ID 127. It triggers on a 100% increase of
ping response times over a 30-minute period.

The Sudden Increase in Disk I/O rule queries profile ID 121. It detects anomalies in disk I/O usage for servers,
VMs, and ESXi hosts over a 30-minute interval. The rule triggers when the read or write volume is more than
3 standard deviations away from the mean over that same time period and the read/write volume is at least 1
Mbps.

The Sudden Increase in Server Process Count rule queries profile ID 117. It detects a sudden increase in
running processes by 25% or more than the average on a server.

Advanced Analytics 6.3 Study Guide 324

 Baseline Rules

DO NOT REPRINT
© FORTINET

The DNS profile can track the volume of DNS requests from a host. Excess DNS requests from a host could
indicate malware running on an end host that could be tunneling data on port 53 to an attacker. In such
situations, the end user is compromised and is unaware of the attack because DNS traffic looks legitimate on
the firewall and is usually not blocked. However, suspicious behavior of this type can be detected by
FortiSIEM by comparing the statistical DNS traffic from the end user and the current DNS traffic. If there is an
anomaly, then an incident will be triggered.

Advanced Analytics 6.3 Study Guide 325

 Baseline Rules

DO NOT REPRINT
© FORTINET

There are two baseline rules that are built into the system for detecting DNS anomaly traffic.

The Sudden Increase in DNS Requests From a Specific Host rule is detected over a 15-minute period. This
rule will trigger if a particular source IP is either generating excessive DNS requests or resolving excessive
distinct names. Excessive DNS requests is defined as at least 100 requests and the current count is 3
standard deviations away from mean for the current hour. Excessive destination names is defined as 50
distinct name resolutions and the current count is more than 3 standard deviations away from the mean for
the current hour. This rule queries the profile ID 113.

The Sudden Change in DNS Data Transfer Pattern From a Specific Host rule is detected over a 15-minute
time period. This rule will trigger when either the sent or received bytes is more than 3 standard deviations
away from the mean and more than 1 MB of traffic is exchanged in the corresponding direction. This rule
queries the profile ID 113.

Advanced Analytics 6.3 Study Guide 326

 Baseline Rules

DO NOT REPRINT
© FORTINET

Baseline rules generally mimic the profile report definition. The subpattern filter and group by definitions for
the baseline rule and the profile report are the same. The baseline rule has its own definition of aggregation
function where it compares the current value of an attribute against the statistical value from the profile
database. However, the aggregation in the profile report is related to the display fields.

Advanced Analytics 6.3 Study Guide 327

 Baseline Rules

DO NOT REPRINT
© FORTINET

The rules engine is using the weighted average and standard deviation values, specifically from each profile
table when the statistical rule functions are referenced. The min and max values are not used by the rules
engine.

Advanced Analytics 6.3 Study Guide 328

 Baseline Rules

DO NOT REPRINT
© FORTINET

The format of the statistical average and standard deviation rule functions is the name followed by the
aggregation, attribute, and profile ID arguments.

Advanced Analytics 6.3 Study Guide 329

 Baseline Rules

DO NOT REPRINT
© FORTINET

Now analyze the statistical average CPU utilization. Average CPU utilization is a very common performance
attribute when you are monitoring any system in your organization. In the profile database, there will be four
columns for this aggregated value, as shown on this slide. The statistical average is simply the moving
average value of the average CPU utilization column from profile 109 in the profile DB.

Advanced Analytics 6.3 Study Guide 330

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows an analysis of the statistical average of matched events for the firewall denied aggregate
traffic profile. In the profile database, there will be four columns for this aggregated value as shown on this
slide. The statistical average is the moving average value of the average matched events column from profile
108 in the profile database.

Advanced Analytics 6.3 Study Guide 331

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows an example of the statistical standard deviation of the sum of sent bytes for the baseline
profile 113. The sent bytes will also have four columns in the profile database as shown on this slide. If a
baseline rule needs to evaluate an aggregate function and requires the standard deviation value for an
attribute, then that value will be loaded into the memory. This is the case for any baseline values stored in any
profile.

Advanced Analytics 6.3 Study Guide 332

 Baseline Rules

DO NOT REPRINT
© FORTINET

One commonly used aggregate expression in the out-of-the-box baseline rules is to determine whether the
current actual aggregation, such as the average, count, or sum, is X times more than the statistical average.

Advanced Analytics 6.3 Study Guide 333

 Baseline Rules

DO NOT REPRINT
© FORTINET

The numpoints column value in the profile database plays an important role when rules evaluate any attribute.
The importance of the numpoint is to prevent premature triggering of a rule before a baseline is set and
becomes active. The rules engine will therefore fetch only values from the profile database that have a
numpoints value equal to two or more. This value is defined in the phoenix_config.txt file, and it can be
changed by the administrator.

Advanced Analytics 6.3 Study Guide 334

 Baseline Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn in detail about an out-of-the-box rule—Sudden Increase in Failed Logons To A
Host. This is a baseline rule that requires baseline data to evaluate the aggregate function.

Advanced Analytics 6.3 Study Guide 335

 Baseline Rules

DO NOT REPRINT
© FORTINET

The profile report for 122 is defined in the backend XML file. The table summarizes the filter, group by
attributes, and display fields attributes that are defined in the backend XML file.

Advanced Analytics 6.3 Study Guide 336

 Baseline Rules

DO NOT REPRINT
© FORTINET

The display column of the baseline report returns the selected SQLite database columns from profile 122.
Profile Date Type, Hour of Day, Reporting Device, and Reporting IP are the group by attributes. Avg
Matched Events, Avg Distinct User, and Avg Distinct Source IP are the aggregate functions.

Advanced Analytics 6.3 Study Guide 337

 Baseline Rules

DO NOT REPRINT
© FORTINET

The baseline rule that is built into the system to monitor a sudden increase in failed logons to a host monitors
for a sudden 50% increase of failed logons to a specific host over a 30-minute period.

The subpattern logon for the rule is monitoring for event types that belongs to the Dev Logon Failure group.
The events of logon failure types are grouped by Reporting Device and Reporting IP.

If the matched events count is greater than or equal to 10, and the matched events count is greater than or
equal to 1.5 times the statistical average of profile 122, then an incident will be triggered.

Advanced Analytics 6.3 Study Guide 338

 Baseline Rules

DO NOT REPRINT
© FORTINET

Take a look at the baseline for a sudden increase in failed logons to a host.

At the start of hour 15, the rule engine will load the statistical average value for the matched events count for
profile 122 from the profile DB. It will load only the statistical average value if the numPoints for that hour is
greater than or equal to 2. In the example shown on this slide, it will load 10 for ServerA and 8 for ServerB
from the profile database into the memory.

The rule engine wakes up at 15:30 and evaluates the failed logon events for the past 30 minutes. Neither
server matches the count and the count is not 50% more than the statistical average.

Advanced Analytics 6.3 Study Guide 339

 Baseline Rules

DO NOT REPRINT
© FORTINET

The rule engine again evaluates the events for a 30-minute period at 15:40. This time it does not need to load
the statistical average values from the profile database to memory because they are already cached.

This time ServerA matches the rule, with an event count of 16 which is greater than 10 as defined in the rule,
and it is also greater than 1.5 times the statistical average value that was loaded into the memory from profile
122.

Advanced Analytics 6.3 Study Guide 340

 Baseline Rules

DO NOT REPRINT
© FORTINET

When a baseline rule triggers, sometimes you will need to review the rule definition to identify why it triggered.
In the example shown on this slide, only the aggregate condition appears as the filter attribute, but not the full
expression.

Advanced Analytics 6.3 Study Guide 341

 Baseline Rules

DO NOT REPRINT
© FORTINET

The incident details returns the number of matching events and the statistical average for the current hour for
the host IP or host name that was cached from the profile database. However, the Detail column does not
display the actual results of the aggregation expression because it is defined in the rule.

Advanced Analytics 6.3 Study Guide 342

 Baseline Rules

DO NOT REPRINT
© FORTINET

In this section, you will learn about the Z-score and which rules use the Z-score to evaluate the aggregate
function.

Advanced Analytics 6.3 Study Guide 343

 Baseline Rules

DO NOT REPRINT
© FORTINET

In statistics, the standard score or Z-score is the number of standard deviations a given data point or value is
away from the mean. To calculate the Z-score, subtract the mean from each data point and divide the result
by the standard deviation.

A positive Z-score indicates the data point is above average and a negative Z-score indicates the data point is
below average.

Advanced Analytics 6.3 Study Guide 344

 Baseline Rules

DO NOT REPRINT
© FORTINET

Data that is two standard deviations below the mean will have a Z-score of -2. Data that is two standard
deviations above the mean will have a Z-score of +2.

As a general rule of thumb, Z-scores beyond +2 or -2 are unusual, while Z-scores beyond +3 or -3 can be
considered highly unusual.

Advanced Analytics 6.3 Study Guide 345

 Baseline Rules

DO NOT REPRINT
© FORTINET

There are many rules on FortiSIEM that use the Z-score for aggregate functions. One such example is the
rule that detects a sudden increase in firewall connections.

The statistical average and statistical standard deviation firewall session values are fetched from profile 112
and loaded into the memory for the hour of the day that is under evaluation. The statistical average firewall
session is subtracted from the average firewall session, which is a real value, and divided by the statistical
standard deviation value of the firewall session.

If the result is greater than or equal to 3 and the statistical standard deviation value of the firewall session is
greater than 0, then the rule will trigger an incident.

Advanced Analytics 6.3 Study Guide 346

 Baseline Rules

DO NOT REPRINT
© FORTINET

The Sudden Decrease in Reported Events From a Host rule detects that a reporting device is suddenly
reporting fewer events. The current average over the 1-hour period is less than three times the standard
deviation and also 50% less than the statistical mean.

Advanced Analytics 6.3 Study Guide 347

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows some of the traffic–related baseline rules.

The Sudden Increase in Firewall Permitted Inbound Traffic to a Specific TCP/UDP Port rule detects traffic
anomalies on inbound TCP/UDP port usage on a firewall. This means that over a 30-minute period, the
permitted inbound traffic—both number of flows and total bytes—to a specific TCP/UDP port is more than 3
standard deviations away than the average for the current hour.

The Sudden Increase in Firewall Permitted Outbound Traffic to a Specific TCP/UDP Port rule detects traffic
anomalies on outbound TCP/UDP port usage on a firewall. This means that over a 30-minute period, the
permitted outbound traffic—both number of flows and total bytes—to a specific TCP/UDP port is more than 3
standard deviations away than the average for the current hour.

The Sudden Increase in Firewall Denied Inbound Traffic to a Specific TCP/UDP Port rule detects anomalous
denied inbound traffic profiled on a specific TCP/UDP port over a 30-minute period. This rule will detect both
the total number of denies and the number of unique source IP addresses are at least 3 standard deviations
away from the mean for the current hour.

The Sudden Increase in Firewall Denied Outbound Traffic to a Specific TCP/UDP Port rule detects anomalous
denied outbound traffic profiled on a specific TCP/UDP port over a 30-minute period. This rule will detect both
the total number of denies or the number of unique destination IP addresses are at least 3 standard deviations
away from the mean for the current hour.

Advanced Analytics 6.3 Study Guide 348

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows some of the logon related baseline rules.

The Sudden Increase in Successful Logons to a Host rule detects a 50% increase in successful logons to a
host over a 30-minute period.

The Sudden Increase in Reported Events From a Host rule monitors for reporting devices that are suddenly
reporting more events. The rule will trigger if the current average over a 30-minute period is more than 3 times
the standard deviation and also 50% more than the statistical mean.

The Sudden Decrease in Reported Events From a Host rule monitors for reporting devices that are suddenly
reporting fewer events. The rule will trigger if the current average over the 1-hour time period is less than 3
times the standard deviation and also 50% less than the statistical mean.

The Sudden Increase in Failed Logons to a Host rule monitors for a sudden 50% increase in failed logons to a
specific host over a 30-minute period.

Advanced Analytics 6.3 Study Guide 349

 Baseline Rules

DO NOT REPRINT
© FORTINET

This slide shows some of the monitoring response times baseline rules.

The ping, SNMP, and WMI response times rules detect for a sudden increase in the response times of these
protocols over a 30-minute period.

The Sudden Increase in ICMP Requests From a Host rule monitors for hosts making excessive ICMP
requests—both the volume and the number of distinct destinations. The rule triggers when the requests are
more than twice the statistical average and at least 100 ICMP requests.

Advanced Analytics 6.3 Study Guide 350

 Baseline Rules

DO NOT REPRINT
© FORTINET

You can tune the rules to avoid generating incidents during certain time periods. You configure this in the rule
exceptions. You can define the attributes and the values for which you do not want to trigger an incident.

In the example shown on this slide, the incident will not be triggered for a 30-minute period at night when a
backup is performed on the host 10.0.0.10 during weekdays.

Advanced Analytics 6.3 Study Guide 351

 Baseline Rules

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to analyze out-of-the-box baseline rules,
and create your own baseline rules with statistical expressions.

Advanced Analytics 6.3 Study Guide 352

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about UEBA on FortiSIEM. You will also learn about the benefits of using UEBA
and various deployment modes of the UEBA agent.

Advanced Analytics 6.3 Study Guide 353

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding UEBA on FortiSIEM, you will be able to configure UEBA on
agents and track UEBA events on FortiSIEM.

Advanced Analytics 6.3 Study Guide 354

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

In this section, you will learn about UEBA and how you can deploy UEBA in a FortiSIEM service provider
environment.

Advanced Analytics 6.3 Study Guide 355

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

FortiSIEM UEBA provides two important functions: visibility and alerting. You can gain visibility into user
endpoint activity, view the files and processes users access on their machines, and search historical logs for
reporting or threat hunting. If there is anomalous user behavior, the FortiSIEM AI generates an incident. You
can customize alerts with tags, and build rules to generate an incident when a known bad behavior is
observed on endpoint devices.

The integration with FortiInsight brings user and entity behavior analytics (UEBA) to FortiSIEM. Previous
versions provided the integration using an API, which required two separate installations. This integration
requires a single installation only, with no overlapping functionality. The AI module runs on super and worker
nodes. All agent activity is routed to one node in a sticky manner. If a worker is down, agent events are routed
to another worker. If a worker is added, new agents are routed to that worker. Additionally, AI models are now
persistent across AI module restarts.

Advanced Analytics 6.3 Study Guide 356

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The agent-based UEBA is lightweight, and captures five key metrics: user, process, device, resource, and
behavior. To reduce endpoint overhead, UEBA events are uploaded to FortiSIEM for analysis. The UEBA
events are collected directly from the kernel of the device, therefore they are accurate and reliable. UEBA
agents do not rely on the audit policy configuration of windows, and the events are uploaded through a secure
channel.

Advanced Analytics 6.3 Study Guide 357

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

Using the UEBA agent provides the following benefits:

Activity is logged on the host

• Increases visibility
• Logged before network encryption
• Can see filename details
Off-net client visibility
• Offline data caching
• Upload to the public collector
Low client overhead
• Approximately 1% CPU use
• All analysis is performed by FortiSIEM
Minimally invasive solution
• No screen or keystroke logging
• No detailed web activity logging
• Minimal performance impact
Detailed endpoint visibility
• Extensive file access logging
• Removable media use
• Program and process use

Advanced Analytics 6.3 Study Guide 358

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The AI module of FortiSIEM, together with the rule engine, can detect known and unknown threats. The AI
module is primarily responsible for building the AI model and identifying anomalies in that model. The rules
detect compliance breaches and known threats.

Advanced Analytics 6.3 Study Guide 359

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The rule engine detects incidents based on how it is configured to analyze logs. Rules are designed to track
and generate incidents for known persistent bad behavior. The AI engine on the other hand learns and builds
its model over time, and no configuration is required. When an anomaly is detected by the AI engine an
incident is generated.

Advanced Analytics 6.3 Study Guide 360

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The phFortiInsightAI process is responsible for building the AI model on FortiSIEM. By default it takes 14 days
to build the AI model, during this period, it is in training mode. After the AI model is built, it switches to
detection mode. When it is in detection mode, the phAnomaly process is responsible for detecting anomalies
that arise. The AI model continues to build and mature the model over time. Events that are anomalous, have
the attribute PH_ANOMALY.

Advanced Analytics 6.3 Study Guide 361

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The AI module runs on super and worker nodes. All agent activity is routed to one node in a Sticky manner.
Once the events are uploaded to a FortiSIEM cluster then the actual UEBA models are distributed across the
workers, but each worker monitors a set of devices to maintain the AI model. If a worker is down, agent
events are routed to another worker. If a worker is added, then new agents are routed to that worker. AI
models are now persistent across AI module restarts.

Advanced Analytics 6.3 Study Guide 362

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

Agents deployed at endpoint devices generate UEBA events which are uploaded to a collector. The collector
uploads the events to the Supervisor or Worker. The UEBA events are then routed to a worker node in a
sticky manner. This stickiness is based on the Reporting Device Name which ensures that the same worker
receives the same device events to build the complete model, rather than fragmented between worker nodes.
The phFortiInsightAI process on the worker continues to build the AI model by extracting various attributes
from the UEBA events. The phAnomaly process generates an alert event if it detects an event that deviates
from the AI model and is suspicious. The anomaly event is summarized on per UEBA rule basis by the
phRuleWorker on the worker and the summarized data is sent to the supervisor. The phRuleMaster on the
supervisor analyzes the event and generates an incident based on the active UEBA rules on FortiSIEM.

Advanced Analytics 6.3 Study Guide 363

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

In this section, you will learn about various deployment options of FortiSIEM UEBA.

Advanced Analytics 6.3 Study Guide 364

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

FortiSIEM offers two distinct features for UEBA agents. When the agent is deployed on endpoint devices,
such as PCs and laptops, then it can be used to monitor end user activity. If the agent is deployed on servers,
it can be used to collect more detailed information regarding the OS, file integrity monitoring, the processes
running on the server, and collect only custom logs. The same Windows agent is deployed Windows server
and on the Windows endpoint devices. The major difference is that you can enable UEBA for endpoint
devices through the Windows agent template and that instructs the agent at the endpoint devices to collect
UEBA events.
There are three different types of UEBA deployment scenarios: on network only, on/off network with VPN, and
on/off network over the internet.

Advanced Analytics 6.3 Study Guide 365

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

For on-net setup, the agents communicate directly with the collectors on the network. The events from the
endpoint devices are uploaded directly to the collector or supervisor. The endpoint device is always on the
corporate network and has direct access to the supervisor or collector. Health information for the agent is
reported directly to the supervisor. If the endpoint devices do not have direct access to the supervisor, it can
connect through a proxy to the collector, and then communicate to the supervisor. The collector can be used
to proxy the health information to the supervisor.
The advantage of this setup is that it is a simple configuration and it can be appropriate for certain
organizations that require endpoint devices to be on the network at all times. The disadvantage is that if the
endpoint devices move outside the organization, it becomes difficult to monitor those devices.

Advanced Analytics 6.3 Study Guide 366

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

To address the issue of off network, you can deploy the agent to communicate directly with a collector that is
deployed on the network when the device is on the corporate network. When the endpoint device is off the
network, you can establish a VPN connection to the corporate network, and then upload the events to a
separate collector located on a DMZ network. To report the health of the agent, the collector on the DMZ
network could proxy the information to the supervisor. If the supervisor can be reached directly through the
VPN, the endpoint devices could report the health status directly to the supervisor. The advantage is that you
can monitor the endpoint devices when they are on the network and when they are off the network. The
disadvantage is that you require the VPN connection to upload events to the collectors.

Advanced Analytics 6.3 Study Guide 367

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

In this setup, the agents communicate to the collector in an off-network environment through the internet. This
model requires some DNS configuration because the agent must communicate with the collector without a
VPN connection. When the endpoint device is on the network the DNS record must point to the collector that
is located inside the network. In the example on this slide the DNS record would point to the internal collector
IP address when the agent is on the network.
For an off-network environment, you should configure your public DNS server with the same FQDN, but it
should point to the public IP address of the firewall. Also, you must configure a VIP on the firewall to map the
public IP address to the private IP address of the collector that is located on the DMZ network.
Your internal and your public DNS should a resolvable DNS name pointing to the appropriate collector. Then,
agents can communicate to the supervisor via a proxy through the collector to report agent health information.

Advanced Analytics 6.3 Study Guide 368

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

In this section, you will learn about the UEBA rules, event types, parser, dashboard, incident page, report, and
watchlist. You will also learn how to configure UEBA tags.

Advanced Analytics 6.3 Study Guide 369

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The UEBA alerts dashboard displays UEBA incidents by severity, top UEBA hosts, top UEBA applications, top
UEBA tags, top users, and so on. You can also add your own customized UEBA widgets.

Advanced Analytics 6.3 Study Guide 370

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

There are 38 built-in UEBA reports on FortiSIEM. You can clone any built-in report, and then edit it to
customize the report according to your requirements. FINS-Windows and FortiInsight-AiAlert are
two distinct event types that identify UEBA events.

Advanced Analytics 6.3 Study Guide 371

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

This slide shows an example of a UEBA report of all incidents generated by the AI engine.

Advanced Analytics 6.3 Study Guide 372

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

There is a dedicated watchlist for UEBA entities that can be populated dynamically as long as you define a
FortiInsight Alert watchlist on the UEBA rule. The entries in the watchlist expire after seven days. If you want
to permanently keep specific entries, you must set the expiry for those entries to Never, so that they are kept
in the database indefinitely.

Advanced Analytics 6.3 Study Guide 373

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The UEBA rules are defined in the /opt/phoenix/data-definition/rules directory. The name of the
XML file is FIN_UEBA_RULES.xml. All UEBA rules belong to the UEBA group called PH_SYS_RULE_UEBA.

Advanced Analytics 6.3 Study Guide 374

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

There are 50 out-of-box UEBA rules on FortiSIEM. A few of these rules are active by default, while others are
inactive. You activate or deactivate a rule based on your requirements. You cannot delete the built-in UEBA
rules, but you can clone and customize the rules.

Advanced Analytics 6.3 Study Guide 375

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

There are 51 built-in UEBA event types on FortiSIEM. You can clone and modify any of those built-in event
types or you can create your own UEBA event types.

Advanced Analytics 6.3 Study Guide 376

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

There are 16 built-in FortiInsight Windows event types on FortiSIEM. You can clone and modify any of these
built-in event types or you can create your own UEBA event types.

Advanced Analytics 6.3 Study Guide 377

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The FortiInsightNativeParser is a built-in parser that recognizes FortiInsight Windows agent logs. The logs
sent by the UEBA agent that is installed on a Windows endpoint is parsed by this parser. The event type is
mapped to FINS-Windows-Generic. The parser identifies logs that have the string FortiInsight-
Windows-Agent msg.

Advanced Analytics 6.3 Study Guide 378

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

For the Windows agent to collect UEBA events, you must enable UEBA on the Windows agent monitor
template. You must also ensure that your FortiSIEM license supports UEBA.

Advanced Analytics 6.3 Study Guide 379

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The process of building the AI model is continuous. The model matures over time, and the more data that is
fed into the AI model, the more accurate the model is at predicting anomalies. When new logs come in to the
AI model, features from those logs are extracted and feed into the AI model. If an event appears to deviate
from the AI model, an anomaly alert is triggered.

Advanced Analytics 6.3 Study Guide 380

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The UEBA Higher Risk Entities dialog box contains the following fields. All of the fields are optional. In each
field, use the + and - buttons to add or remove entries.
File Types: Enter the type of file you want to monitor.
File Paths: Enter the path to the folder you want to monitor.
User Accounts: Enter the name of the Windows agent-side user account you want to monitor.
Group Names: Enter the name of the Windows agent-side group you want to monitor.

Advanced Analytics 6.3 Study Guide 381

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

FortiInsight attempts to categorize anomalous events using tags. AI inspects the events for specific
characteristics, as defined in the AI tag definitions, and applies the appropriate tags to events that match.
Setting tags in FortiSIEM allows you to identify the FortiInsight tags that you want FortiSIEM to monitor. Tags
modify risk weighting which is applied to all inbound logs. Tags can increase or decrease the associated risk
displayed in the GUI, but they do not change the underlying AI model.

Advanced Analytics 6.3 Study Guide 382

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

The UEBA incident dashboard shows the UEBA incidents that the AI module creates.
The attribute list table provides the following information about AI alerts received from FortiInsight:
Incident: the name of the incident that was detected.
Host: the host name or IP address where the alert originated.
Application: the name of the application that is the source of the incident.
User: the Windows agent user.
Tag: the tag used to categorize the alert.
Activity: the description of the activity that raised the alert.

Advanced Analytics 6.3 Study Guide 383

 FortiSIEM UEBA

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to deploy FortiSIEM UEBA in a multi-
tenant environment and identify key implementation requirements. You also learned about the UEBA rules,
event types, parser, reports, watchlist, as well as the importance of UEBA tags in determining the risk level of
UEBA incidents.

Advanced Analytics 6.3 Study Guide 384

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the MITRE ATT&CK® framework and how it categorizes attacks in various
techniques and tactics. You also learn how incidents on FortiSIEM fit into the MITRE ATT&CK framework.

Advanced Analytics 6.3 Study Guide 385

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in MITRE ATT&CK, you will be able to determine the tactic and technique of
an attack. You can build rules and configure the appropriate MITRE technique for a rule, so that when an
incident is generated by that rule, an analyst is able to identify the technique and quickly take action on that
incident based on pre-defined solutions. You will also learn about FortiGuard malware resources on
FortiSIEM.

Advanced Analytics 6.3 Study Guide 386

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

In this section, you will learn about MITRE ATT&CK framework and various tactics and techniques.

Advanced Analytics 6.3 Study Guide 387

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

MITRE ATT&CK is a global knowledge base of real-world adversary attack TTPs. The knowledge base has
been populated with popular attacks and techniques used by various attack groups over the years such as
APT3, APT29, and so on. ATT&CK maps various techniques to tactics so that it becomes easy to identify
similar attacks.

Advanced Analytics 6.3 Study Guide 388

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

Very often SOC teams use the term TTP, which stands for tactics, technique, and procedure.

Tactics describe the immediate technical objectives the attackers are trying to achieve, such as gaining initial
access, maintaining persistence, or establishing command and control. Invariably, attackers must use multiple
tactics to successfully complete an attack.

Techniques describe the methods attackers use to achieve a tactic. All tactics in each matrix have multiple
techniques. The enterprise matrix breaks some techniques down further into sub-techniques. An example of
this is the phishing technique attackers use to gain initial access. The three sub-techniques associated with
the phishing technique are spearphishing attachment, spearphishing link, and spearphishing through service.

Procedures describe the specific implementations of techniques and sub-techniques APTs have used
(sometimes in clever or novel ways), or it can refer to specific malware or other tools attackers have used.

Advanced Analytics 6.3 Study Guide 389

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

There are 14 different tactics and each tactics has multiple techniques and every technique may have several
sub-techniques.

Advanced Analytics 6.3 Study Guide 390

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The technique numbering starts with the letter T followed by a four digit technique number and after the
decimal there is a three digit sub-technique number if there is a sub-technique associated with that technique.

For example, the phishing technique is T1566 and it has three different sub-techniques called spearphishing
attachment, spearphishing link, and spearphishing through service.

Advanced Analytics 6.3 Study Guide 391

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

Groups are sets of related intrusion activity that are tracked by a common name in the security community.
Analysts track clusters of activities using various analytic methodologies and terms such as threat groups,
activity groups, threat actors, intrusion sets, and campaigns. Some groups have multiple names associated
with similar activities due to various organizations tracking similar activities by different names. Organizations'
group definitions may partially overlap with groups designated by other organizations and may disagree on
specific activity.

OilRig is an example of a group that used several tactics and techniques. It is a suspected threat group that
has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of
industries, including financial, government, energy, chemical, and telecommunications, and has largely
focused its operations within the Middle East. It appears the group carries out supply chain attacks, leveraging
the trust relationship between organizations to attack their primary targets.

Advanced Analytics 6.3 Study Guide 392

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

In this section, you will learn about MITRE ATT&CK on FortiSIEM.

Advanced Analytics 6.3 Study Guide 393

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can define MITRE techniques in a rule and the associated tactics gets populated automatically. Incidents
generated by the rule contain details of tactics and techniques. From the incident coverage view you can view
incidents mapped to the MITRE framework. From the incident explorer view you can view details of incidents
and drill down to incidents and explore the MITRE tactics and techniques. From the rule coverage view you
can view all rules on FortiSIEM mapped to the MITRE framework.

Advanced Analytics 6.3 Study Guide 394

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

Over 900 built-in rules on FortiSIEM are associated with MITRE ATT&CK techniques. The technique and
tactic can be applied to system rules or custom rules.

Advanced Analytics 6.3 Study Guide 395

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

All existing rules are mapped to MITRE ATT&CK tactics and techniques where applicable. You can add
Techniques to your own custom rule or you can edit the Techniques of the built-in rules. You can select
multiple techniques or sub-techniques in a rule. The tactics are populated based on the techniques that you
select.

Advanced Analytics 6.3 Study Guide 396

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The rule coverage view provides an overview of the tactics and techniques that FortiSIEM covers as defined
by MITRE Corporation. The top row displays the number of rules and the percentage of MITRE techniques
that FortiSIEM covers. In the main row header, the bolded number that appears under each tactic indicates
the number of rules that are covered under it. Clicking a tactic here will show all the rules that belong to it.
Each tactic cell also lists the number of major techniques (Tech) and subtechniques (Sub-Tech) related to the
involved tactic. All major techniques related to a tactic are listed underneath their respective tactic column.
Tactics and techniques covered by FortiSIEM rules are indicated by a light yellow background.
You can hover your mouse cursor over any major technique to view the following information:
• Total number of rules covered by the technique (security category)
• The number of rules covered by each sub-technique (if applicable)

Advanced Analytics 6.3 Study Guide 397

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The incident coverage view provides an overview of the security incidents detected by FortiSIEM that fall
under the tactics and techniques as defined by MITRE Corporation. The top row displays the number of
incidents detected by FortiSIEM in the time range specified. In the main row header, the bolded number that
appears under each tactic indicates the number of incidents associated with a specific tactic. Clicking a tactic
will show all related detected incidents. Each tactic cell also lists the number of major techniques (Tech) and
sub-techniques (Sub-Tech) related to the involved tactic/incidents. All major techniques related to a tactic are
listed underneath their respective tactic column. Tactics and techniques covered by FortiSIEM rules are
indicated by a light yellow background.
You can hover your mouse cursor over any major technique to view the following information:
• Total number of incidents triggered by this technique
• The number of incidents triggered by each sub-technique (if applicable)

Advanced Analytics 6.3 Study Guide 398

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The MITRE ATT&CK incident explorer view maps security incidents detected by FortiSIEM into attack
categories defined by MITRE Corporation. The incident explorer shows a host centric, interactive ATT&CK
view. The number in the middle of the circle indicates the number of incidents in that category. The size of the
circle is relative to the number of incidents. The color of the circle indicates the severity of the incident:
red=HIGH severity, yellow=MEDIUM severity, and green=LOW severity.

Advanced Analytics 6.3 Study Guide 399

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can populate the table in any of these ways:

• Click a device to see all of the incidents associated with the device
• Click the Tactics drop-down list and choose one of the attack categories
• Click the number in the middle of the circle to view incidents for a specific device and for a specific tactic

Advanced Analytics 6.3 Study Guide 400

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can access top level MITRE ATT&CK data from within FortiSIEM. If you need more information on a
Technique then you can click on the Technique link directly from FortiSIEM and that will redirect you to the
MITRE ATT&CK webpage where more detailed information is available for that technique.

Advanced Analytics 6.3 Study Guide 401

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

In this section, you will learn about a MITRE ATT&CK on FortiSOAR.

Advanced Analytics 6.3 Study Guide 402

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The MITRE ATT&CK knowledge base is used as a foundation for the development of specific threat models
and methodologies.

This MITRE ATT&CK connector helps to import MITRE ATT&CK techniques from the static data available
within the connector and adds the data to FortiSOAR in MITRE ATT&CK Techniques module. This helps in
replicating the knowledge base of adversary tactics and techniques based on real-world observations.

Advanced Analytics 6.3 Study Guide 403

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

The MITRE ATT&CK Techniques module imports 525 techniques after the MITRE connector is executed. You
can add your own technique to the module.

Advanced Analytics 6.3 Study Guide 404

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

From the MITRE ATT&CK Technique module you can open and view any technique. Every technique has the
following information:
Description: describes the technique
Detection: describes the process of detecting the attack
Mitigation: describes the process of mitigating the attack
References: provides external reference for more information
Threat Actors: lists the threat groups associated with this technique
Tools: describes various tools used during attack process
Malware: describes any malware associated with the technique
Related Records: lists the incidents or alerts associated with this technique on FortiSOAR

Advanced Analytics 6.3 Study Guide 405

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

Alerts and Incidents contains the MITRE ATT&CK Correlations section where techniques are added by
playbooks or where manually you can link a technique to the alert or to an incident. This makes it easy for
SOC analyst to quickly identify a MITRE technique related to an incident and take mitigation action against an
attack.

Advanced Analytics 6.3 Study Guide 406

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

In this section, you will learn about malware resources on FortiSIEM.

Advanced Analytics 6.3 Study Guide 407

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

FortiGuard IOC provides reputation checks for different malware like IP, domain, URL, and hash. Reputation
checks can be invoked in two ways:
• When an incident triggers, users can manually do a lookup through FortiGuard IOC, virus total, or RiskIQ.
Any external website can also be looked up, but the results of FortiGuard IOC, VirusTotal or RiskIQ are
parsed and the user is provided with a simplified verdict (safe, unsure, or malicious based on thresholds).
• Users can automate reputation checks by including it in their incident notification policies. When included,
the reputation check will automatically be done when an incident triggers. Incident comments are updated
with the results.

Every licensed FortiSIEM can do FortiGuard IOC lookup. No special configuration is required.

Advanced Analytics 6.3 Study Guide 408

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can configure external integration to FortiGuard and other third-party platforms through the integration
policy. To configure FortiGuard IOC lookup, select the Incident in the Type drop-down list and Outbound in
the Direction drop-down list.. The Instance name can be any instance that has not been used earlier or you
could select the default name that is populated by default. Configure the plugin name as shown on this slide.

After you configure the integration policy, then you can either run the policy manually from the Incidents page
or you can configure the notification policy to run the policy automatically, when an incident is created.

Advanced Analytics 6.3 Study Guide 409

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can execute an integration policy manually through the Actions tab on Incidents page. You can run a
different integration policy on the same incident. The result is inserted in the Comments section of the
incident, which provides the user with a simplified verdict.

Advanced Analytics 6.3 Study Guide 410

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

After an incident triggers, the user may want to take an action. You can automate this process through the
notification policy. One action in the notification policy is to invoke an integration policy. You can select an
integration policy to run on a specific rule or on any rule. If an incident is generated by that rule, then the
integration policy is triggered against that incident.

Advanced Analytics 6.3 Study Guide 411

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

You can populate the FortiGuard Malware IPs, FortiGuard Malware Domains, and FortiGuard Malware URLs
database on FortiSIEM. After the databases are populated, you can configure rules to trigger an incident if an
indicator is part of that database.

Advanced Analytics 6.3 Study Guide 412

 MITRE ATT&CK®

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to map rules to the MITRE ATT&CK
framework and understand MITRE tactic and technique. You also learned about integrating various threat
intelligence platforms to FortiSIEM.

Advanced Analytics 6.3 Study Guide 413

 Clear Conditions

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the clear conditions that the system requires to clear an incident
automatically.

Advanced Analytics 6.3 Study Guide 414

 Clear Conditions

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding the generation of incident procedures, you will be able to
define conditions the system requires to clear an incident automatically.

Advanced Analytics 6.3 Study Guide 415

 Clear Conditions

DO NOT REPRINT
© FORTINET

In this section, you will learn about incident status and how you can clear incidents by defining clear
conditions. You will also walk through the process of clearing an incident for a server that is not responding to
a ping response.

Advanced Analytics 6.3 Study Guide 416

 Clear Conditions

DO NOT REPRINT
© FORTINET

FortiSIEM generates incidents when it detects issues. The incident will be placed into an active state. This is
fine for security-related incidents because operators will want to review each incident for compliance
purposes. However, for availability or performance-related problems, servers and network devices may
experience only temporary issues. For example, when you come to investigate the CPU, memory, or network
interface thresholds, they may be back to normal already. Therefore, FortiSIEM provides all rules, with the
ability to automatically change an active incident status to auto-cleared based on an extra set of defined
criteria.

Advanced Analytics 6.3 Study Guide 417

 Clear Conditions

DO NOT REPRINT
© FORTINET

This slide shows an example of a rule with a defined clear condition. This rules is tracking a server using
ICMP packets, and when there is no response to ICMP packets from the server, FortiSIEM triggers an
incident. The status of the incident is set as active. After the server comes back up and starts responding to
ICMP packets again, the incident will be cleared automatically by the system because of the defined clear
condition.

Advanced Analytics 6.3 Study Guide 418

 Clear Conditions

DO NOT REPRINT
© FORTINET

In the following slides, you will walk through the rule that detects if a device is responding to pings. During a
120-second window, if 10 out of 10 ping packets are lost, then either the host is down or there is a routing
problem.

There are two subpatterns for this rule. If any one of the subpatterns meets the conditions, then the rule will
trigger an incident.

Advanced Analytics 6.3 Study Guide 419

 Clear Conditions

DO NOT REPRINT
© FORTINET

Take a look at the subpattern shown on this slide. The filter is tracking event types, which is specifically for
monitoring device performance and availability using pings. The filter also ensures that the ping monitoring
events are coming from server devices.

FortiSIEM groups all the events by their host IP and host name, which are the server IP and server name.

After the events are grouped, FortiSIEM performs the aggregate function. If the average packet loss
percentage is equal to 100% and the matched events count is greater than or equal to 1, then FortiSIEM
triggers an incident.

Advanced Analytics 6.3 Study Guide 420

 Clear Conditions

DO NOT REPRINT
© FORTINET

Take a look at the system shutdown subpattern shown on this slide. The filter is tracking event types that
belongs to the system down event type category, which is defined in the CMDB. The filter also ensures that
the reporting IP belongs to the server devices.

FortiSIEM groups all the events by their reporting IP and reporting device, which are the server IP and server
name.

After the events are grouped, FortiSIEM will perform the aggregate function. If the matched events count is
greater than or equal to 1, then FortiSIEM will trigger an incident.

Advanced Analytics 6.3 Study Guide 421

 Clear Conditions

DO NOT REPRINT
© FORTINET

Let’s focus on the pattern shown on this slide.

The pattern on this slide shows that FortiSIEM will poll the server every 2 minutes and collect the ping stats.
Based on those ping stats it creates an event. If only 5 out of 10 pings fail, then it is considered a 50% packet
loss and FortiSIEM will not generate an incident.

In this example, it’s a 100% packet loss, which means all 10 pings failed, which will trigger an incident.

Advanced Analytics 6.3 Study Guide 422

 Clear Conditions

DO NOT REPRINT
© FORTINET

The action on the rule generates the incident that is based upon the filter attributes in the subpattern.

In the example shown on this slide, the Host IP and Reporting IP defined in the subpattern filter are the same
so they are mapped to the incident as the Host IP. The Host Name and the Reporting Device defined in the
subpattern filter are similar, so they are mapped to the incident as the Host Name.

Advanced Analytics 6.3 Study Guide 423

 Clear Conditions

DO NOT REPRINT
© FORTINET

The incident is generated when there is no ping response from the server. From the Incident Type you can
identify which subpattern triggered the incident. In the example shown on this slide, the incident type is
PH_RULE_NON_RESPONSIVE_SERVER, which means that the AllPingLossSrv subpattern triggered the
incident.

Because this is the first occurrence of the incident, the count will be 1 and the First Occurred and Last
Occurred times will be the same.

Advanced Analytics 6.3 Study Guide 424

 Clear Conditions

DO NOT REPRINT
© FORTINET

FortiSIEM remembers which events the incident was triggered for. When the phRuleMaster wakes up 30
seconds later and evaluates the 2-minute window, it will not trigger additional incidents for the same triggering
event.

Advanced Analytics 6.3 Study Guide 425

 Clear Conditions

DO NOT REPRINT
© FORTINET

When the phRuleMaster wakes up again after 30 seconds and evaluates the 2-minute window, it will not
trigger additional incidents for the same triggering event.

Advanced Analytics 6.3 Study Guide 426

 Clear Conditions

DO NOT REPRINT
© FORTINET

Because this is a performance-related metric, FortiSIEM polls the server periodically and, in the example
shown on this slide, it is 2 minutes. The evaluation window is also for 2 minutes and for that reason, in most
cases, there will be only one matching event.

When FortiSIEM polls the server again in 2 minutes, a new event will be generated with 100% average packet
loss. When the phRuleMaster wakes up again and evaluates the 2-minute window, it will trigger the incident
caused by the new triggering event. The incident ID will be the same as before. It will just update the count,
last occurred, and event details for the same incident ID.

Advanced Analytics 6.3 Study Guide 427

 Clear Conditions

DO NOT REPRINT
© FORTINET

The new incident data is merged with the current active incident. The Count is increased to 2 and the Last
Occurred time is updated.

Advanced Analytics 6.3 Study Guide 428

 Clear Conditions

DO NOT REPRINT
© FORTINET

This process will continue while the server is still at 100% packet loss. After 2 minutes, when the
phRuleMaster wakes up again and evaluates the 2-minute window, it will detect a new triggering event with
100% packet loss. The incident count will be updated to 3.

Remember that the phRuleMaster is actually waking up every 30 seconds to evaluate all the active rules. It
will update the incident only if there is a new triggering event.

Advanced Analytics 6.3 Study Guide 429

 Clear Conditions

DO NOT REPRINT
© FORTINET

Again, after 2 minutes when the phRuleMaster wakes up and evaluates the 2-minute window, it will detect a
new event with 0% packet loss. At this point, the rule conditions do not match the event and no incident will be
triggered or updated. The problem has been resolved, but without applying any other logic, the incident will
still display as active on the incident dashboard.

Advanced Analytics 6.3 Study Guide 430

 Clear Conditions

DO NOT REPRINT
© FORTINET

Since the problem has gone away, this is where you can define a rule clear condition. Clear conditions can
either be time based or pattern based.

Time based means that the original rule did not trigger again for a specified period of time, which can be
specified in seconds, minutes, or hours.

Pattern based means that a new subpattern should be evaluated to watch for an alternative condition to occur.

The end result is that the incident will change from an active status to an auto-cleared status.

Advanced Analytics 6.3 Study Guide 431

 Clear Conditions

DO NOT REPRINT
© FORTINET

If the clear condition is time-based, then with a 5-minute clear window, the incident will auto clear after the last
occurrence of the incident. The clearance window begins from the last time the incident was triggered and, if
the incident triggers again during that window, then the window is reset.

Advanced Analytics 6.3 Study Guide 432

 Clear Conditions

DO NOT REPRINT
© FORTINET

With a pattern-based clear condition, a subpattern needs to be defined, which could be a single or multiple
pattern definition. Usually, it is almost an exact mirror of the original pattern in the rule but with a different
aggregation calculation.

Advanced Analytics 6.3 Study Guide 433

 Clear Conditions

DO NOT REPRINT
© FORTINET

The clear condition is defined using the Clear setting in the rule definition. The clear condition is available on
all rules but you need to define the conditions. However, availability and performance rules have a default
clear condition predefined.

You need to define an association between the original rule’s incident attributes and the clear condition
incident attributes to ensure that the incident that is being cleared is associated with the original rule.

In the example shown on this slide of a pattern-based clear condition, if the average packet loss is less than
10% and if it matches at least one event, then the incident will be cleared.

Advanced Analytics 6.3 Study Guide 434

 Clear Conditions

DO NOT REPRINT
© FORTINET

This is a conceptual explanation of a pattern-based clear condition.

The phRuleMaster wakes up to evaluate the events for the past 2 minutes. Based on the rule subpattern,
there is 100% packet loss. The rule will update the count value of the previous incident because it is the third
occurrence of the event.

Since the average packet loss is still at 100%, it does not match the clear condition defined for that rule.

Advanced Analytics 6.3 Study Guide 435

 Clear Conditions

DO NOT REPRINT
© FORTINET

The phRuleMaster will wake up again in 2 minutes and evaluate the events for the past 2 minutes. This
time, the packet loss percentage is 0% and that will trigger the clear condition subpattern.

The rule will compare the host IP from the event that triggered the clear condition with the host IP of the
original rule that triggered the incident. If the host IP addresses match, that means that the same server that
was not responding to the ping is now responding, and the incident status will be set to auto cleared.

Advanced Analytics 6.3 Study Guide 436

 Clear Conditions

DO NOT REPRINT
© FORTINET

You can verify the status of the incident on the INCIDENT tab. You will see that the incident status for those
incidents that have been cleared by the system. Because the incident satisfies clear conditions, the status will
be set to auto cleared.

Advanced Analytics 6.3 Study Guide 437

 Clear Conditions

DO NOT REPRINT
© FORTINET

By mastering the objectives covered in this lesson, you learned how to define the conditions that the system
requires to clear an incident automatically.

Advanced Analytics 6.3 Study Guide 438

 Remediation

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about remediation on FortiSIEM, which can be done either on an ad hoc basis or
using a notification policy, where the system takes the remediation action when an incident happens. You will
also learn to remediate incidents through FortiSOAR. You will learn about various deployment architectures of
FortiSOAR.

Advanced Analytics 6.3 Study Guide 439

 Remediation

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding remediation, you will be able to remediate incidents manually
or automatically through FortiSIEM or FortiSOAR.

Advanced Analytics 6.3 Study Guide 440

 Remediation

DO NOT REPRINT
© FORTINET

In this section, you will learn the basics of remediation, and how remediation is performed on FortiSIEM.

Advanced Analytics 6.3 Study Guide 441

 Remediation

DO NOT REPRINT
© FORTINET

Remediation is the FortiSIEM ability to respond to detected network and security threats and operational
device conditions. Time to detection and time to respond are metrics security teams have sought to reduce for
a very long time. With remediation, IT security teams can stay in control of their IR activities and respond to
threats and intrusions swiftly and effectively. This decreases time to resolution, with less operator interaction
while minimizing mistake-prone manual processes.

Advanced Analytics 6.3 Study Guide 442

 Remediation

DO NOT REPRINT
© FORTINET

In this conceptual case, if FortiGate generates an event that triggers a rule, which in turn will trigger an
incident, then you have the option to define the way you want to remediate the incident. You can configure a
notification policy, which can be defined to automatically run a FortiGate block IP script. You could also run
the same script manually from the incident tab at any time, where the incident has already occurred.

Advanced Analytics 6.3 Study Guide 443

 Remediation

DO NOT REPRINT
© FORTINET

This slide shows some of the out-of-the-box remediation scripts that are available on FortiSIEM. As of release
6.3, there are 30 remediation scripts for devices such FortiGate, Linux, and Windows.

Advanced Analytics 6.3 Study Guide 444

 Remediation

DO NOT REPRINT
© FORTINET

The automatic remediation actions are defined in the notification policy. You can select multiple actions for
every incident, such as blocking the IP, emailing the SOC team, and also raising a service ticket. Select Run
Remediation/Script in the notification policy configuration.

Advanced Analytics 6.3 Study Guide 445

 Remediation

DO NOT REPRINT
© FORTINET

There are two types of script options. Legacy script is the scripting option supported in previous FortiSIEM
and AccelOps releases. Remediation is using the new built-in scripts in FortiSIEM 5.0 and beyond.

Advanced Analytics 6.3 Study Guide 446

 Remediation

DO NOT REPRINT
© FORTINET

A legacy script requires an absolute path to the script to be specified. Usually either a bash or python script.
This script would be manually placed on the supervisor or collectors by a FortiSIEM administrator who has
administrative ownership and execute permissions.

Advanced Analytics 6.3 Study Guide 447

 Remediation

DO NOT REPRINT
© FORTINET

If you choose to use a remediation script, then you can select an out-of-the-box or user-defined script and
specify the enforcement device. Starting from FortiSIEM version 5.0 and later, system, and new user-defined
remediation scripts are stored in the CMDB.

Advanced Analytics 6.3 Study Guide 448

 Remediation

DO NOT REPRINT
© FORTINET

The Enforce On setting identifies the device that the script will be taking the action on, such as logging in to a
network device to block or shun an IP, or rebooting a server.

If the Enforce On value is defined then the remediation script will use this as a variable on the FortiSIEM
backend. Otherwise, if left blank, the out-of-the-box scripts will try to determine the Enforce On device
through the incident XML.

Enforce On is optional for both automatic remediation in the notification policy or manual remediation on the
Incident tab. However, it is recommended to always specify a value.

Advanced Analytics 6.3 Study Guide 449

 Remediation

DO NOT REPRINT
© FORTINET

You can select one or more devices from the CMDB on which the script needs to be enforced. In that case,
when an incident is generated, then the script will be run on multiple devices. If an incident, such as a zero-
day attack, is detected on one device, then you can run a script across multiple devices to block the attacker
before the attack occurs on other devices.

In the example shown on this slide, a malicious IP is detected by the first FortiGate, which reports that event
to FortiSIEM. The remediation script would then SSH to both FortiGate devices and then execute the
remediation script which, in this case, is to quarantine the malicious IP address.

Advanced Analytics 6.3 Study Guide 450

 Remediation

DO NOT REPRINT
© FORTINET

The Run On setting tells FortiSIEM where to attempt to run the remediation script from. The default value is
the supervisor node, but the device may be reachable through a remote collector. If you have defined
collectors for any organization, then by default the run on resource is the collector for that organization.

Advanced Analytics 6.3 Study Guide 451

 Remediation

DO NOT REPRINT
© FORTINET

You can run remediation scripts manually from the incident dashboard by selecting Remediate Incident from
the Actions menu.

Advanced Analytics 6.3 Study Guide 452

 Remediation

DO NOT REPRINT
© FORTINET

The benefit of using automatic remediation is that external threats or attacks will be blocked as soon as they
are detected, no matter what time of day. The concept of automatic remediation is already used widely across
organizations in antivirus, spam patching, and so on.So it is just another layer of security on top of your
existing automated security framework.

The disadvantage of automatic remediation is that the script can potentially make disruptive changes to a
user, blocking access to an application or disconnecting critical systems from the network, causing more harm
than good.

Advanced Analytics 6.3 Study Guide 453

 Remediation

DO NOT REPRINT
© FORTINET

The advantages of manual remediation are that the administrator has control over what action is being taken
and can follow and track the process of the remediation action. You can gather further useful context on a
host after an incident is triggered if you are performing manual remediation.

The disadvantage of manual remediation is that external threats or attacks that are detected by FortiSIEM will
need user interaction to apply the action, which can be time consuming for an overworked SOC team. Those
threats that occur at night can take hours to respond to, and during that time more systems could be
compromised. Running manual remediation is equivalent to running an IPS in monitor-only mode—watch but
do not block.

Advanced Analytics 6.3 Study Guide 454

 Remediation

DO NOT REPRINT
© FORTINET

In this section, you will learn how remediation scripts work on FortiSIEM.

Advanced Analytics 6.3 Study Guide 455

 Remediation

DO NOT REPRINT
© FORTINET

When a script action is defined on FortiSIEM, then the device will generate an XML extract of the incident
data. The contents of the XML file will be different for each incident. FortiSIEM then calls the script with the
XML file name as an argument. After the script returns, the incident XML file is deleted to avoid any confusion
with the next script action.

By default, FortiSIEM-generated incident output files, remediation scripts, and script responses will be saved
in a temporary folder. The incident files have the name incident followed by some random characters. If
you are running a remediation script, then the script is copied over to the device that is executing the script
with the script name followed by random characters. The response from the script is saved with the filename
do_system followed by random characters.

If you are running only a legacy script, then the script is executed from the location where the script is stored.
For legacy scripts, you will see only the incident and script response file. Since these files are almost
immediately deleted, it can be hard to catch the output.

Advanced Analytics 6.3 Study Guide 456

 Remediation

DO NOT REPRINT
© FORTINET

This is an example of an incident XML file where a malware was found by a firewall but was not remediated.
You can remediate this incident using a remediation script that would extract relevant information from the
incident such as source IP, file name, and so on. The information that the script gathers from the incident XML
file can be used to perform actions, such as configuring or editing a firewall policy to block any future
occurrence of the malware or virus.

Advanced Analytics 6.3 Study Guide 457

 Remediation

DO NOT REPRINT
© FORTINET

Every incident has a unique ID, which is tagged with XML attributes. There are XML tags and within those
tags you can define XML attributes.

The ruleType attribute defines the ID of the rule, which is the rule event type that was created. The
severity attribute defines the value between 1-10 where 1-4 is low severity, 5-8 is medium severity, and 9-
10 is high severity. The repeatCount attribute defines the number of times the incident has occurred.

The organization attribute defines which organization was impacted in service provider deployments. In
enterprise deployments this organization is always Super.

The status attribute defines the incident status where 0 means the incident is active, 1 means the incident
was auto cleared, 2 means the incident was manually cleared, and 3 means the incident was cleared by the
system.

Advanced Analytics 6.3 Study Guide 458

 Remediation

DO NOT REPRINT
© FORTINET

This slide shows another example of an incident XML file. This incident was generated because the rule
detected that a user made some changes to domain controller user and computer settings. This incident file
has user and targetUser as incident attributes. The user is the person who made the changes and the
target user is the one whose account was changed or modified.

Advanced Analytics 6.3 Study Guide 459

 Remediation

DO NOT REPRINT
© FORTINET

This slide shows some XML tags and their definitions.

Advanced Analytics 6.3 Study Guide 460

 Remediation

DO NOT REPRINT
© FORTINET

This slide shows an example of an automated remediation script for port scanning.

In the notification policy, you select the rules for which the remediation will be performed. You must define the
script before you can enable Run Remediation Script. While defining the script, you can select the Enforce
On and Run On options. Enforce On is optional, but it is recommended that you configure this setting. If you
don’t configure Enforce On, then the script will pick the Enforce On setting from the incident XML file.

In the example shown on this slide, the script is selected to block a malicious IP on FortiGate.

Advanced Analytics 6.3 Study Guide 461

 Remediation

DO NOT REPRINT
© FORTINET

If an incident is generated, then the script will read the source IP from the XML file. The source IP is specified
with the incidentSource tags.

There can be different types of XML attributes depending on the type of source. In the example shown on this
slide, the source IP address will be extracted from the XML file and action will be taken on that IP address,
which is considered a malicious IP.

Advanced Analytics 6.3 Study Guide 462

 Remediation

DO NOT REPRINT
© FORTINET

FortiSIEM now logs on to FortiGate with SSH using the stored credentials on the CMDB to execute the
commands necessary to quarantine the offending IP address. You can view the banned IP on FortiGate by
navigating to the Quarantine Monitor page. You can also view the banned IP in the CLI by running the
command diagnose user quarantine list.

Advanced Analytics 6.3 Study Guide 463

 Remediation

DO NOT REPRINT
© FORTINET

FortiSIEM records all successful and failed remediation in backend events. These can be queried using
System Event Category 3, which is not shown in analytics by default and the
PH_INCIDENT_ACTION_STATUS event type.

Advanced Analytics 6.3 Study Guide 464

 Remediation

DO NOT REPRINT
© FORTINET

In the example shown on this slide, for some reason, the remediation script fails, and FortiSIEM records the
reason for the failure. In the example shown on this slide, the script failed to execute because the file system
on FortiGate was corrupt. Sometimes, FortiSIEM will also provide a solution to the problem, such as
suggesting that you run commands on FortiGate to resolve the issue.

Advanced Analytics 6.3 Study Guide 465

 Remediation

DO NOT REPRINT
© FORTINET

All out-of-the-box remediation scripts are located in a remediations directory. These are Python V2 scripts,
and some call on the existing expect scripts used for configuration pulling. These scripts are loaded into the
CMDB and should not be manually edited from this file location. User-defined scripts on the GUI are also
stored in the CMDB, but are not present in this directory.

Advanced Analytics 6.3 Study Guide 466

 Remediation

DO NOT REPRINT
© FORTINET

In this section, you will learn about mitigating incidents through FortiSOAR.

Advanced Analytics 6.3 Study Guide 467

 Remediation

DO NOT REPRINT
© FORTINET

Typically, the remediation process on FortiSOAR begins with the extraction of IOC from alerts. There could be
several different types of indicators in an alert. Through the indicator extraction playbook you can extract
those indicators. After the indicators are extracted, you must run the enrichment playbook to enrich those
indicators by querying third-party threat intelligence platform. Finally, you can block any malicious indicators
through a playbook by connecting to an edge device or to an endpoint device.

Advanced Analytics 6.3 Study Guide 468

 Remediation

DO NOT REPRINT
© FORTINET

Use the By Connector Names tab to first choose a specific connector, and then choose the operation that
you want that connector to perform. Or use the By Actions tab to first choose the action that you want to
perform, and then choose the connector that you want to use to perform the selected action.

The By Connector Names tab displays all the connectors that are configured in your system. Use this tab if
you want to use a specific connector to perform a particular action. Use the Search Connectors section to
search for connectors by name.

An annotation can have multiple connectors configured to perform that action, and, if more than one connector
can perform the same action, then a list of connectors is displayed when you click the name of the action.

Advanced Analytics 6.3 Study Guide 469

 Remediation

DO NOT REPRINT
© FORTINET

From version 6.4.1 and later, you must specify whether you want to run the action on the current FortiSOAR
node, or remotely on the agent node, by clicking the Self or Agent buttons besides Target. By default, Self is
selected, which means that the action will run on the current FortiSOAR node. Then you must select the
configuration by clicking the Configuration drop-down list to select the action, because the FortiSOAR node
can have multiple configurations. Configurations are based on the configuration names that you specify when
you are configuring the connector.

You can install different versions of a connector, and, while adding a connector operation, you can specify a
specific version of a connector within a playbook. If the version of the connector specified in the playbook is
not found, then the playbook uses the latest version by default.

The return from the execute function is set in the results.data variable of the playbook step.

Advanced Analytics 6.3 Study Guide 470

 Remediation

DO NOT REPRINT
© FORTINET

Use the Utilities connector for performing operations in FortiSOAR, such as performing a FortiSOAR search
using the Query API, updating a FortiSOAR resource, and creating a FortiSOAR resource. This connector
also contains other useful utilities, such as extracting email metadata, like indicators, from an email file,
uploading a file to FortiSOAR and associating that file with an attachment, such as providing the File IRI in the
output, converting file formats, such as XML to JSON or CEF to JSON, and zipping and password protecting a
file. This connector is ready to use, and you do not need to configure this connector.

One of the utilities on FortiSOAR is FSR: Make FortiSOAR API Call. You can use this action to call an API
within FortiSOAR and perform various actions. You can use HTTP methods such as GET, POST, PUT,
DELETE, and PATCH. In the example shown on this slide, a DELETE http method is used for every item
from a previous step. The for each will run for every item in the array that is fetched by the step named
Find_All_Alerts and then delete them.

Another example is using the GET function of http method. This will retrieve users from the IRI
/api/3/people.

Advanced Analytics 6.3 Study Guide 471

 Remediation

DO NOT REPRINT
© FORTINET

The XML to Dictionary is another useful utility that you can use to covert XML data to dictionary format. The
dictionary data is in JSON style and preserves the nesting level structure in XML data. For example, if the
XML data has five levels of nesting, the dictionary data will also have five levels of nesting. The data within an
XML tag is considered to be the value and the XML tag itself is considered the key. In dictionary format, it will
form the key-value pair.

Advanced Analytics 6.3 Study Guide 472

 Remediation

DO NOT REPRINT
© FORTINET

Once you convert an XML data to the dictionary, you can use that dictionary data in any remaining playbook
step.

Advanced Analytics 6.3 Study Guide 473

 Remediation

DO NOT REPRINT
© FORTINET

There are other FortiSOAR utilities that you can use in your playbook. This slide lists the other utilities that are
available to you while designing a playbook.

Advanced Analytics 6.3 Study Guide 474

 Remediation

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how to remediate incidents manually and
automatically.

Advanced Analytics 6.3 Study Guide 475

DO NOT REPRINT
© FORTINET

No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2021 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.