DO NOT REPRINT
© FORTINET
FortiEDR Study Guide
for FortiEDR 4.2
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
12/29/2020
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
01 Overview and Technical Positioning
02 Installation and Architecture
03 Administration
04 Best Practices and Deployment
05 The User Interface in Depth Part 1
06 The User Interface in Depth Part 2
07 Events and Alerting
08 Help Desk Level 1 Triage
09 Communication Control
10 Next-Generation Antivirus
11 Threat Hunting
12 RESTful API
13 Multi-Tenancy
14 Fortinet Cloud Service
15 Advanced Troubleshooting
16 Endpoint Security 101
17 PowerShell and CScript
18 Alert Analysis 401
4
20
41
73
93
120
147
170
184
214
225
240
260
282
296
313
337
355
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about what FortiEDR does and how it can help customers save time and
resources.
FortiEDR 4.2 Study Guide
4
Overview and Technical Positioning
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 technical positioning of FortiEDR, you
will be able to describe what FortiEDR is, how it works, and its benefits.
FortiEDR 4.2 Study Guide
5
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR answers the malware challenge: how do you stop an attack that hasn’t been invented yet? The
malware landscape is constantly changing. New threat families appear regularly, and existing ones are
constantly evolving into new, harder-to-detect variations. AV-TEST registers about 350,000 new malicious
and unwanted programs every day, totaling more than one billion samples. How can security programs keep
up?
FortiEDR 4.2 Study Guide
6
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR uses a different approach to detect malware. Most security software focuses on the point of
infiltration. It’s a little bit like a bouncer at a club—they’re trying to keep out anyone who might cause trouble.
Once someone gets in though, they’re not being watched as closely, so if they cause trouble—if they start a
fight, for example—they’re going to create some disruption before they get kicked out.
FortiEDR watches for malicious actions—attempts to steal or alter your data—then follows the chain from the
point of the consequences back to the source of the initial process.
FortiEDR 4.2 Study Guide
7
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
Now you will explore a quick overview of what FortiEDR offers. First and foremost, FortiEDR offers reliable
protection. With pre-infection and post-infection protection, FortiEDR can stop even a highly sophisticated
attack before it can inflict harm. FortiEDR also offers centralized management. You can administer your entire
organization from a single console, eliminating alert clutter. FortiEDR is also highly scalable. It is a lightweight
agent that can be deployed in a small local company, or in a giant international corporation. It’s also highly
flexible. FortiEDR works with a broad range of operating systems, and can continue to protect, even when a
device is offline. Lastly, FortiEDR can save you money by eliminating both post-breach operational expenses
and breach damage.
FortiEDR 4.2 Study Guide
8
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
One of the biggest problems companies face is the response gap burden. They have malware prevention
software and they use manual EDR to respond to threats that get through their antivirus solutions. This
approach introduces dwell time. An attacker only needs a few seconds to steal or encrypt data, so by the time
the EDR team has been notified of a threat, the attacker has had plenty of time to inflict damage. It’s also an
expensive solution. It requires a team to respond to alerts at any hour, evaluate each process, and determine
whether a threat is genuine. If the threat is real, the team must determine the best course of action and then
manually take steps to contain and remediate the threat.
FortiEDR 4.2 Study Guide
9
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR eliminates the response gap by automating EDR. If malware gets through the Next Generation
Antivirus (NGAV) filter, FortiEDR can still stop it in real time, before it causes harm. With the immediate threat
blocked automatically, you can investigate the incident and remediate devices on your own time.
FortiEDR 4.2 Study Guide
10
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
What about cost? Compared with manual EDR, FortiEDR saves you time. All of these steps—monitoring,
detection, data enrichment, and validation—can take just under half an hour to more than two hours to
complete, plus another fifteen minutes, on average, to escalate and block the incident. FortiEDR can do all
that automatically in real time, right out of the box. FortiEDR also offers the ability to configure automated
incident response to contain and remediate infections. That can save you hours of manual effort.
FortiEDR 4.2 Study Guide
11
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR can also save you resources. To adequately staff a manual EDR team, you’ll need L1 and L2 SOC
analysts, security engineers, incident handlers, forensic investigators, hunt analysts, and managers. FortiEDR
automates the process, so you need fewer people to do the same job.
FortiEDR 4.2 Study Guide
12
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
The FortiEDR NGAV platform has been rated best in class by the independent testing organization, AV-TEST.
In real-world testing, AV-TEST found FortiEDR NGAV protected against 100% of malware attacks, including
web and email threats. FortiEDR was also found to block 100% of widespread and prevalent malware, with a
false positive rate of just a thousandth of a percent.
FortiEDR 4.2 Study Guide
13
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
Another independent testing institute, NSS Labs, gave FortiEDR the prestigious Recommended rating in the
2018 and 2019 Advanced Endpoint Protection groups. NSS Labs gave FortiEDR a score of 100% in blocking
against malware that executes offline through email, web downloads, documents, and scripts, and 100% in
blocking evasions commonly able to bypass layered security products. Like AV-TEST, NSS Labs found that
FortiEDR had a false positive rate of only a thousandth of a percent.
FortiEDR 4.2 Study Guide
14
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
This slide shows what FortiEDR offers, in a little more depth. First, FortiEDR offers real-time next-generation
antivirus. Using machine learning and a continuously-updated cloud database, FortiEDR detects known or
simple threats and blocks them from executing.
Next, FortiEDR offers real-time proactive risk mitigation. This gives you automated control over the nonmalicious applications communicating over your network. FortiEDR will discover any application that
establishes a connection and track its activity. FortiEDR offers reputation scoring and CVE data on each
application version, allowing you to quickly identify whether an application that is not actively malicious might
present a risk. You can use the reputation or CVE scores to proactively block any application version with
known vulnerabilities or a poor reputation. That means, if a new vulnerability is detected in an old version of
Google Chrome, for example, you can configure FortiEDR to block that version automatically, the moment the
vulnerability is published, but still allow safer versions to access the internet. This reduces your attack surface.
Next is real-time detection and containment. If a sophisticated attack manages to get past FortiEDR NGAV,
post-infection detection and blocking are activated. FortiEDR monitors the operating system at the kernel
level. At every attempt to establish a connection, modify a file, or delete a file, FortiEDR evaluates the process
and determines whether it is likely to be malicious. If there are indicators of malicious activity, the attempt is
immediately blocked.
Lastly, FortiEDR offers real-time orchestrated incident response. Every event is automatically classified based
on how likely it is to be malicious. Based on that classification, you can configure a set of automated actions,
including opening tickets, isolating the device, or remediating the threat.
FortiEDR 4.2 Study Guide
15
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
This slide provides a look at the order of operations. First, there is pre-execution filtering and attack surface
reduction, or risk mitigation. If the attack is sophisticated enough to bypass NGAV, it encounters post-infection
protection. The file starts to run, but FortiEDR stops it before it can do harm by encrypting or stealing data. To
do this, the collector collects OS metadata and takes snapshots every time a process attempts to establish a
network connection or modify a file. The collector sends the snapshot to the core for evaluation. The core
analyzes the data, determines whether the attempt is legitimate, and sends instructions to the collector
indicating whether to allow or block the connection or file modification. If a malicious actor gets in, FortiEDR
blocks it from doing any harm.
FortiEDR 4.2 Study Guide
16
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR is automated endpoint security realized. It offers:
•
A comprehensive platform: a universal lightweight agent that offers next-generation antivirus and
automated EDR for out-of-the-box protection. There is no learning period involved.
•
Automated security: real-time protection from malware, both pre-execution and post-execution.
•
Automated event management: automated and customized course of action carried out with no
additional staff.
FortiEDR 4.2 Study Guide
17
Overview and Technical Positioning
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
18
Overview and Technical Positioning
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 what FortiEDR does and how it can help
customers save time and resources.
FortiEDR 4.2 Study Guide
19
Installation and Architecture
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about FortiEDR components, how they are configured, and how to install them.
FortiEDR 4.2 Study Guide
20
Installation and Architecture
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in installation and architecture, you will be able to install FortiEDR components
and configure key elements of your deployment.
FortiEDR 4.2 Study Guide
21
Installation and Architecture
DO NOT REPRINT
© FORTINET
Start by identifying the major components that make up a FortiEDR installation. The first component is the
FortiEDR collector—the lean collector, or agent, that sits deep inside the operating system, down at the kernel
level, and sees everything that happens on the device. It is installed on all the systems in your enterprise.
The core is the security policy enforcer and decision maker. It determines whether a connection establishment
or write to disk operation is legitimate or should be blocked. The core may run on-premises, in the cloud, or a
combination of both. If the collector is offline, it uses built-in policies at the collector level, to operate in
autonomous mode. That means if the collector can’t connect to the core, the device is still protected at the
collector level.
The threat hunting repository is an optional feature requiring a threat hunting license. It allows administrators
to find and delete malware from any system within the enterprise.
The FortiEDR aggregator provides processing and load handling services for the central manager. The
FortiEDR central manager is the user interface and the back-end server for reviewing and analyzing events
and configuring the system. In smaller deployments, these two components are usually installed on the same
server. Larger deployments will require separate servers, and very large deployments may require multiple
aggregators.
FortiEDR 4.2 Study Guide
22
Installation and Architecture
DO NOT REPRINT
© FORTINET
Now you’ll learn how FortiEDR components communicate, starting with the FortiEDR collector. The first thing
it does after it’s installed is connect to the aggregator, which sends back a license and a configuration file. In
that configuration file is a list of cores that the collector is allowed to talk to. There can be up to 11 cores
communicating with one aggregator. The collector then checks the connection time to each core and chooses
to use the fastest one.
The core handles policy enforcement. If there is a risky type of event, the collector sends compressed
operating system metadata to the core for evaluation. The core sends back a go or no-go on the event based
on existing policies. It then sends the alert data and the policy action to the aggregator, which passes it to the
central manager. The central manager displays this data in the GUI. The core also sends alert data to Fortinet
Cloud Service (FCS), which conducts a deeper analysis of events. You will learn more about FCS later in the
course. Lastly, the core sends information about executables detected on each collector to the threat hunting
repository. It communicates to the central manager, where you can search for executables on the GUI.
FortiEDR 4.2 Study Guide
23
Installation and Architecture
DO NOT REPRINT
© FORTINET
Take a look at the typical enterprise deployment. The vast majority of our customers use a cloud-based
central manager and cores, and some supplement that with a local core. This slide shows an example that
explains why this model works well. This organization has on-site cores to support its servers, and a cloudbased core to support the cloud data center. But how does this work with employees? When workers are in
the office, they can communicate with the on-premises core, so their compressed metadata doesn’t need to
go out over the network. But workers aren’t always in the office. When they’re working at home or on the road,
they’re covered by the cloud-based core. So no matter where you are, you can connect to a core.
FortiEDR 4.2 Study Guide
24
Installation and Architecture
DO NOT REPRINT
© FORTINET
The collector lives at the kernel level inside the operating system. While new operating systems bring a lot of
changes over time, not a lot changes at the kernel level. So FortiEDR supports all the way back to Windows
XP, service pack 2, and all the way up to the latest versions of Windows 10. On the server side, FortiEDR
supports Windows Server 2003, release 2, service pack 2, all the way up to latest versions of Windows Server
2019.
For a Mac operating system, FortiEDR supports Yosemite through Catalina. For Linux, FortiEDR supports
Red Hat Enterprise Linux and its freeware version, CentOS version 6.8 through 6.10, and 7.2 through 7.7, all
in 64-bit. FortiEDR supports Ubuntu LTS version 16.04.6, 18.04.1, and 18.04.2 server in 64-bit. For
VMware, FortiEDR supports Horizon 6 and 7 and Citrix XenDesktop 7.
Note that the list of supported operating systems is dynamic. For the latest list, consult the latest version of the
FortiEDR Installation and Administration Guide, or contact Fortinet support.
The collector requires an Intel or AMD x86 hypervisor-compatible processor, either 32-bit or 64-bit. The space
requirements for the collector are minimal—you need 60 MB of RAM and 20 MB of disk space.
Every collector requires one end-user license. If FortiEDR detects that a collector is running on a server, you
will require a server license. For licensing purposes, all Linux machines are considered servers.
FortiEDR 4.2 Study Guide
25
Installation and Architecture
DO NOT REPRINT
© FORTINET
Now you will learn about the server requirements. These requirements apply only to on-premises or hybrid
deployments. Server deployments are supported by the Fortinet professional services team.
The core, aggregator, and central manager may be installed on a dedicated workstation or server or on a
virtual machine. Installers are supplied in ISO format, including a CentOS 7 image. You can install the
aggregator and central manager together on one machine, or for larger deployments, you can install them
separately. Also, note that in versions 3.1 and later, the core is installed on a Linux system, rather than
Windows.
For disk space and memory, the core requires at least 8 GB of RAM and at least 60 GB of disk space. The
aggregator, central manager and threat hunting repository all require 16 GB of RAM. You will need at least 80
GB of disk space for the aggregator, 150 GB for the central manager, and a minimum of 200 GB for the threat
hunting repository.
All server components require Intel or AMD x86 64-bit hypervisor-compatible processors. You’ll need to
assign a static IP address or domain name to the core, aggregator, and central manager, and network
connectivity is required between all system components.
FortiEDR 4.2 Study Guide
26
Installation and Architecture
DO NOT REPRINT
© FORTINET
This slide shows a chart of the full network communication requirements. Communication from the collector to
the aggregator is done on a non-standard port—port 8081—and communication from the collectors to the
core is done on port 555. Those ports are configurable—they can be changed, but most customers leave
them unchanged. Communication from the core to the aggregator uses port 8081, and the core to the threat
hunting repository uses port 443. The same ports are used for communication from the core to reputation
services.
FortiEDR 4.2 Study Guide
27
Installation and Architecture
DO NOT REPRINT
© FORTINET
FortiEDR uses a number of techniques to ensure that the collector runs securely and cannot be disabled by
malware. First, FortiEDR hardens the OS service and folders, forcing the Windows service to interact only
with FortiEDR’s collector driver.
Next, FortiEDR uses random salting locations of the collected metadata to prevent tampering.
Third, anti-debugging techniques are used to prevent anyone from reverse-engineering the FortiEDR
collector code.
Fourth, FortiEDR uses impersonation prevention to prevent a threat actor from impersonating the FortiEDR
collector.
Lastly, FortiEDR supports the non-persistent operating systems VMware Horizon 6 and Citrix XenDesktop 7.
FortiEDR 4.2 Study Guide
28
Installation and Architecture
DO NOT REPRINT
© FORTINET
If a collector can’t reach the core, it goes into autonomous mode. In autonomous mode, the collectors enforce
security policies and communication control policies on their own. When a collector is in autonomous mode,
its status in the management console will be shown as Running (Autonomously). Any alerts generated
while in autonomous mode are not shown in the management console until the collector is back online, but a
copy of any alerts are kept in the local system logs.
FortiEDR 4.2 Study Guide
29
Installation and Architecture
DO NOT REPRINT
© FORTINET
Collectors always connect to the closest available core. Determining the closest is based on the time to travel
to the core. Collectors connect to one core at a time, but they can switch over very quickly to the next core. Up
to 11 cores can be configured per aggregator. The aggregator is typically located on the same server as the
management console, but in excess of about 5,000 machines, the aggregator should be moved to separate
machine. Up to 10,000 collectors can be configured per aggregator. Each central management server can
support up to 100,000 collectors. These scaling numbers are constantly improving. Make sure to check with
Fortinet, or your service provider, before engaging in a large scale deployment.
FortiEDR 4.2 Study Guide
30
Installation and Architecture
DO NOT REPRINT
© FORTINET
The collector is very simple to install. The only information you need is the aggregator’s IP address and the
registration password. The registration password is set during initial management server configuration and
prevents unauthorized users from using your licenses.
On Windows, you can install the collector with an MSI file. You can create a self-installer that is preconfigured
with the aggregator IP address, registration password, organization name for multi-tenancy environments, and
collector group, if needed. Fortinet provides a custom installer generator to create your preconfigured file. In
version 4.1 and later, you can also request a custom installer on the Administration tab of the management
console.
The collector can be delivered in any way you would deliver any other MSI for installation, through a GPO
object or Windows System Center Configuration Manager. An example command line installation script is
shown in the upper-right corner of this slide. You can find detailed instructions in the Installation and
Administration guide.
Installation on a Mac is a DMG file—just run the PKG file enclosed and proceed through the GUI. You can
also create a silent installer for Macs using a JSN file configured with the registration password, aggregator
IP, and any other desired settings. Again, you can find detailed instructions in the Installation and
Administration guide.
You can also install the collector on Linux machines. For Red Hat Enterprise and its freeware version,
CentOS, you can use the provided RPM installer with the correct Linux distribution in the filename. This slide
shows an example installation script for CentOS. After the installation is complete, run FortiEDRconfig.sh
to configure the aggregator IP, registration password, and any other information desired. For Ubuntu, use the
DEB installer. This slide shows a sample script. Again, you’ll need to configure the collector after installation
by running FortiEDRconfig.sh.
If you need help with installation, contact the Professional Services team at Fortinet.
FortiEDR 4.2 Study Guide
31
Installation and Architecture
DO NOT REPRINT
© FORTINET
The registration password is used to authenticate components of your FortiEDR installation. If you're in a
mixed environment, perhaps a university, and you've bought 500 licenses to protect a specific group of users,
you don't want unauthorized users coming in and registering. So, you would protect the installation with a
password that only legitimate uses would know, or only users that have access to the self-installer.
When you install and configure the central manager for the first time, you define an authentication password.
You use that password to authenticate other components in your network. Each collector that registers in your
FortiEDR network must provide the authentication password during installation. If the password is entered
incorrectly, the collector will not register, and the device will not be protected. You also need to provide the
device registration password to disable or uninstall a collector. You can find this password in the
Administration tab, under Tools. In the COMPONENT AUTHENTICATION section, click Display to see the
registration password. Remember that the registration password is case sensitive. You can copy the
password and paste it into any other window you need.
FortiEDR 4.2 Study Guide
32
Installation and Architecture
DO NOT REPRINT
© FORTINET
FortiEDR has three types of policies that work together to maintain your system’s security. The most
important type of policies are security policies. These policies determine whether a process is malicious or
not. Next are playbooks, or automated incident response. If FortiEDR catches a potentially malicious process,
you can use playbooks to automatically remediate the device and protect the rest of your network. Lastly are
communication control policies. These policies apply to programs that are not malicious, but may be insecure
or banned by company policy. Communication control policies decide which applications are allowed to
communicate through the network and which are blocked.
You will learn more about all of these policies in this lesson.
FortiEDR 4.2 Study Guide
33
Installation and Architecture
DO NOT REPRINT
© FORTINET
Now you will learn about security policies. FortiEDR comes out of the box with four security policies, each with
its own purpose. Execution prevention, or next-generation antivirus, stops malicious files from executing. This
policy catches simple or known attacks before they start. If the attack manages to bypass execution
prevention, there are two more policies that will detect suspicious behavior and stop it before it can inflict
harm. Exfiltration prevention stops malicious actors from connecting to the network and stealing data, while
ransomware prevention prevents malicious actors from encrypting your data. In version 4.0 and higher, you
can also enable device control, which detects and blocks the use of specific classes of USB devices, such as
mass storage devices. You don’t have to block mass storage devices, but it’s a really helpful feature in
environments with very sensitive data.
FortiEDR 4.2 Study Guide
34
Installation and Architecture
DO NOT REPRINT
© FORTINET
FortiEDR policies can operate in one of two modes: protection, or blocking mode, and simulation, or logging
mode. When operating in protection mode, FortiEDR actively enforces the policy. In most cases, the event is
blocked in real time, preventing harm to the device or system. If the event is suspicious, but could possibly be
legitimate, FortiEDR logs it for review. When operating in simulation mode, FortiEDR issues an alert, but will
not block any processes. FortiEDR is delivered in simulation mode. Because each policy is set to simulation
or protection mode separately, you can enforce some policies while others are in simulation mode. In the
example shown on this slide, there are three default policies. The three policies are marked with the Fortinet
logo, and are operating in protection mode. The other policies, including the default device control policy, are
in simulation mode.
Policies are cloned to create new ones. Additional policies are useful for new groups or business units that
require their own policies, such as administrators or developers.
FortiEDR 4.2 Study Guide
35
Installation and Architecture
DO NOT REPRINT
© FORTINET
Now you will learn more about how to organize collectors. Each collector belongs to one collector group. You
can create customized collector groups organized by work group, role, geography, or any other criteria that
makes sense for your organization.
Policies are assigned at the collector group level. For full protection, each group should be assigned to one of
each of the following policies: execution prevention, ransomware prevention, exfiltration prevention,
communication control, and playbook. If you are using device control in your organization, you should also
assign a device control policy.
You can assign many groups to a single policy.
FortiEDR 4.2 Study Guide
36
Installation and Architecture
DO NOT REPRINT
© FORTINET
This side shows some best practices for collector groups. FortiEDR comes out of the box with two groups: the
default collector group and the high security collector group. Unless you specify a different collector group
during installation, all collectors are placed initially in the default collector group. It may be in simulation or
protection mode, depending on the environment and deployment stage.
The high security collector group is for collectors that have been infected with malware. Depending on your
settings, devices may be placed there automatically after a malicious event. You’ll learn more about the high
security collector group in this lesson. Fortinet recommends assigning strictly enforced policies to this group.
Working groups are where your collectors will generally be assigned. In early phases of deployment, these
groups will be assigned to policies operating in simulation mode. After tuning is complete, reassign them to
policies operating in protection mode to ensure that they are actively protected.
You should maintain a simulation group for troubleshooting, and assign it to security and communication
control policies in simulation mode. If a user calls technical support, their collector may be placed temporarily
into simulation mode to rule out FortiEDR as the cause. Collectors in the simulation group are not protected,
so they should be kept there for the shortest possible time.
FortiEDR 4.2 Study Guide
37
Installation and Architecture
DO NOT REPRINT
© FORTINET
In some cases, you may want to create multiple policies to accommodate different groups.
For example, newly deployed groups should be assigned to policies in simulation mode until tuning is
complete. However, the high security collector group, should always be assigned to policies in protection
mode, even during deployment. You’ll need to maintain a set of policies in simulation mode and another set in
protection mode.
You may also have collector groups with specific needs that require different settings than other groups. For
example, developers may need certain rules disabled because of the nature of their day-to-day work. You can
create as many copies of policies as you need.
FortiEDR 4.2 Study Guide
38
Installation and Architecture
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
39
Installation and Architecture
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 install and configure FortiEDR.
FortiEDR 4.2 Study Guide
40
Administration
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to administrate a FortiEDR deployment.
FortiEDR 4.2 Study Guide
41
Administration
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in administration, you will be able to configure key elements of your
deployment.
FortiEDR 4.2 Study Guide
42
Administration
DO NOT REPRINT
© FORTINET
In the FortiEDR Installation and Architecture lesson, you learned about FortiEDR policies. Now, you’ll learn
how security policies work. Security policies are at the heart of FortiEDR protection. You can configure your
security policies in the management console—click the Security Settings tab and select Policies. Collector
groups are assigned to policies, which are set to protection or simulation mode at the top level. Remember,
policies in simulation are not actively blocking malware. You’ll see an event in the Event Viewer, but no
process will be blocked. Use policies in simulation mode only for initial tuning or troubleshooting purposes.
Each policy is made up of a set of rules, which are delivered out of the box. Rules are automatically assigned
an action (Log or Block) based on their severity. Management console users can change the assigned action
of an individual rule if desired. Each rule can also be individually enabled or disabled. By default, all rules in
most policies are enabled, and FortiEDR does not recommend disabling them. If you don’t want to enforce a
specific rule, it is better to set it to Log. That way, you will still have a record of the violation if a problem
occurs, but the rule won’t be enforced.
The exception is the device control policy. Its rules are disabled by default. Enable each rule you want to
enforce. For example, if you want to block USB mass storage devices, enable that rule. If you don’t want to
block any type of device, you can leave this policy and its rules in the default state.
FortiEDR 4.2 Study Guide
43
Administration
DO NOT REPRINT
© FORTINET
Device control policies work a little differently than the other three security policies. Some organizations in a
high-security field, like health care, need to restrict USB devices because of industry regulations. Device
control allows you to block specific classes of USB devices, such as mass storage devices, USB hubs, CDCdata devices, or application-specific devices.
As with other security policies, you need to set the device control policy to protection mode to enforce it.
However, in device control, all rules are disabled by default. Find the rule for each device class you want to
block and click the state icon to toggle the state to Enabled. If your organization does not need to restrict USB
devices, you can leave the device control policy in simulation mode and the rules disabled. No device will be
blocked, and no notifications will be generated for USB devices unless they are infected and violate rules in a
different security policy.
FortiEDR 4.2 Study Guide
44
Administration
DO NOT REPRINT
© FORTINET
Every time a process violates a security rule, an event is recorded in the Event Viewer tab of the
management console. Events are aggregated by process or device. Aggregating events makes it easier to
view, prioritize, and handle events. Each view is useful under different circumstances. For example, the
device view is useful if you need to troubleshoot issues involving a particular collector. The process view is
the most efficient way to analyze alerts. To change your view, click the device or process icon. In the example
shown on this slide, you’re viewing by process. You can also see an overview of unhandled events, grouped
by process or device, on the dashboard.
Each top-level row represents an alert—either a device or a process that has violated a rule. Click on an alert
to view the events. In the example shown on this slide, Locky.exe is the highlighted process, and there are
two events in the environment involving this process. Each event is made up of raw data items—individual
operations that are grouped based on the process, attempted action, and rules violated. The number of raw
data items associated with an event is shown on the right side of the event row. You can also see the event’s
classification—in this case, Malicious. You’ll learn more about classifications in another lesson.
FortiEDR 4.2 Study Guide
45
Administration
DO NOT REPRINT
© FORTINET
Device control events are also recorded in the Event Viewer. These are instances of a blocked USB device
attempting to connect to a collector device. To see these events, select device control from the status filter at
the upper-left corner of the events list. Keep in mind that events will be recorded only if they violate a rule
marked as enabled in the Security Settings tab. For example, if you enabled only the USB mass storage
device rule, any mass storage device would be recorded, but a USB mouse would be ignored.
You can allow specific devices within a blocked category by creating exceptions. You can narrow your
exceptions based on the device name or serial number. In the example shown on this slide, the device Cruzer
Glide violated the USB mass storage device rule. In the exception, the device is allowed, but only if it has the
same serial number and name as the device in this event.
FortiEDR 4.2 Study Guide
46
Administration
DO NOT REPRINT
© FORTINET
Communication control policies block connections from specific application versions. You can set rules to
deny communication from certain categories of application versions—for example, if they have a poor
reputation or critical vulnerabilities. You can also create a rule to block all applications from a specified
vendor. Rules are proactive—they apply not only to the current applications and versions in your system, but
also to applications and versions that may be installed later. If someone installs a version of an application
with critical vulnerabilities, for example, FortiEDR will immediately block it from communicating. You can also
manually allow or deny communication from individual applications or versions. For example, if an
application’s reputation score is 4 but it’s on your company’s block list, you can mark it as Deny.
Communication control policies only block connections from an application. Users can still run blocked
applications offline. This reduces productivity blockers while protecting your system from unsafe connections
from unsafe applications.
The communication control policies are evaluated after the security policies. So if a process is blocked by a
security policy, then there is no communication for the communication control policy to evaluate.
Like security policies, communication control policies are assigned at the collector group level, and you can
clone them to create specialized policies. So, if you want to allow specific programs for system administrators
but not for other users, you can create a system administrator collector group and assign it to a specialized
communication control policy.
FortiEDR 4.2 Study Guide
47
Administration
DO NOT REPRINT
© FORTINET
Every communication control policy has a default action of Allow or Deny. In almost all cases, the default
action should be Allow. You can then deny communication from specific applications as needed. Setting the
default action to Deny would block all applications from communicating unless you explicitly change them to
Allow. That can impact productivity. The Default Communication Control Policy allows applications to
communicate by default. You can see that in the example on shown on this slide. If you clone that policy to
create new ones, they will also allow communication by default.
The Server Policy is an exception to the rule—it is preconfigured with a default action of Deny. Remember,
this will block all applications from communicating, but in this case, that’s what you want. Servers require a
higher level of security than ordinary workstations, so you set the default to deny, then allow any applications
that the server needs to do its job.
The Isolation Policy is another exception. This policy is applied to any collectors that are put into isolation
mode. Isolation mode is a temporary state applied to devices infected by malware. Blocking communication
from infected devices helps contain the infection. You can modify the Isolation Policy to allow specific
applications to communicate when the device is isolated. For example, you may have some troubleshooting
tools that need to connect to the device during an investigation or remediation. Remember, all applications are
blocked from communicating unless you change their settings—that includes internet browsers, email
applications, and so on.
FortiEDR 4.2 Study Guide
48
Administration
DO NOT REPRINT
© FORTINET
A playbook is an automated set of actions that FortiEDR performs when an event occurs. You can assign
different actions for different classification levels. For example, you may keep notifications enabled for events
at all classification levels, but only terminate the process and clean persistent data when the classification is
malicious.
You can clone a playbook to create versions with different settings. The default playbook comes out of the box
in simulation mode. When a playbook is in simulation mode, you will still receive notifications as configured,
but no other actions will be taken. You can see what FortiEDR would have done in response to a specific
event by looking at the classification details panel in the Event Viewer. You’ll learn more about that in another
lesson. If a playbook is in protection mode, FortiEDR will carry out all actions as configured.
Each collector group is assigned to one—and only one—playbook. By default, all collector groups are
assigned to the default playbook. You will learn more about playbooks in another lesson.
FortiEDR 4.2 Study Guide
49
Administration
DO NOT REPRINT
© FORTINET
On the console, the slider in the upper-right corner of the window is the master slider for protection versus
simulation mode. The master slider is intended for emergency use only, because setting the master slider to
simulation mode places all policies into simulation mode.
Note that when the slider says Protection, like it does in the example shown on this slide, it does not mean
that every collector is assigned to a policy in protection mode. Some collector groups may still be assigned to
policies in simulation mode. Click the down arrow beside the master slider to see a breakdown of how many
collectors are protected by each type of policy. For example, in the donut chart to the right, you can see that
94.1% of collectors are assigned to an exfiltration prevention policy in protection mode. The number will vary
across policy types. When the master slider is set to Simulation, all policies are set to simulation mode and
no collector groups are actively protected.
If you want to place a collector in simulation mode as part of troubleshooting, the best method is to move the
individual collector into a designated simulation group, rather than disturb an entire group. After
troubleshooting is complete, move the collector back into its original group.
FortiEDR 4.2 Study Guide
50
Administration
DO NOT REPRINT
© FORTINET
Now that you understand a bit more about how each type of policy works, you will learn about managing
collectors. You can see a list of all the collectors in your organization on the management console. Click the
Inventory tab and select Collectors. By default, you’ll see only collectors that are in a degraded state. This is
to draw your attention to collectors that are not performing correctly and need your attention. Click Show All
Collectors to see all collectors, organized by collector group. You can also view all collectors by clicking the
drop-down filter at the top of the list and selecting All. You can filter by other states too. You’ll learn more
about collector states in this lesson. Select Unmanaged to view all the workstations and servers in your
system that do not have the FortiEDR collector installed. These devices are not protected.
You’ll notice numbers next to each collector group. These numbers indicate how many collectors you can see
in the current view and the total number of collectors in the group. For example, if you set the filter to show
only collectors that are disabled, you might see only one collector out of the 10 that are in the group.
You can create collector groups by clicking Create Group. Then, select the checkbox for each collector you
want to move, click Move to Group, and select your newly created group.
FortiEDR 4.2 Study Guide
51
Administration
DO NOT REPRINT
© FORTINET
Here’s a short overview of the collector states:
• Running means everything's up and well.
• If the Core is temporarily inaccessible, the collector will enforce policies on its own, and its state will be
shown as Running (Autonomously).
• Disconnected means the device is not connected to the aggregator, often because it’s powered down.
• If a collector hasn’t connected to the system in more than 30 days, FortiEDR will automatically give you
back its license seat. The collector isn’t removed from the system.
• In a few rare cases, generally relating to compatibility issues with anti-virus software, the FortiEDR
collector will need to be rebooted. In these cases, the collector won’t load until after the reboot, and you’ll
see the status listed as Pending Reboot.
• If a collector is Disabled, it was probably disabled from the management console. This may occasionally
be necessary for troubleshooting.
• Degraded shows that there's some sort of issue that's preventing the collector from performing at full
capacity. This should be investigated to identify the source of the problem.
FortiEDR 4.2 Study Guide
52
Administration
DO NOT REPRINT
© FORTINET
Isolation mode and the high security collector group are extra security measures that provide additional
protection to a collector after an attack. These measures can be particularly helpful during deployment when
collectors are still in simulation mode. Should an attack occur during this phase, you can increase security on
any affected collectors without rushing the entire deployment group into protection mode.
FortiEDR comes with a built-in high security collector group, which cannot be deleted. This group is intended
as a temporary quarantine for infected collectors. Fortinet recommends applying strict policies to this group,
and making sure that those policies are always in protection mode.
Isolation mode is also intended to prevent infections from spreading from affected devices. Collectors in this
mode are assigned to a special isolation policy in communication control, which automatically blocks all
application communication by default. If needed, you can configure specific applications, like security or
remediation tools to be allowed to communicate when isolated.
You can configure a playbook to move collectors automatically to the high security group, put them in isolation
mode, or both, after an event. You’ll learn more about playbooks in this lesson. You can also manually move a
collector to the high security collector group, or place it in isolation mode from the Inventory tab in the
management console. Being in the high security group or operating in isolation mode are intended as
temporary states. So, after you are sure a device has been remediated, restore it to its usual collector group
and take it out of isolation mode. You can do this from the Inventory tab as well.
FortiEDR 4.2 Study Guide
53
Administration
DO NOT REPRINT
© FORTINET
Always make sure you’re using the latest collector version on all devices. New versions of the collector are
delivered through content updates, which you can upload on the Administration tab of the management
console under Licensing. You can upgrade collectors remotely from same place. Fortinet recommends
deploying collector updates in smaller batches to avoid any problems. When moved to a new collector group,
collectors check for updates, so any major changes to collector group assignment should also be done in
phases.
In the example shown on this slide, Update Collectors was clicked to open the Update Collector Groups
window. The Acme-Protect group, which is currently running Windows version 3.1.0 Rev 407, is shown in the
example. The Windows checkbox was selected, and version 4.1.0 Rev 259 was selected in the drop-down
list. When you click Update, the selected group will begin updating.
FortiEDR 4.2 Study Guide
54
Administration
DO NOT REPRINT
© FORTINET
FortiEDR allows you to customize the information your end users receive about the collector and its activities.
You can configure these settings in Administration > Tools.
You can enable system tray icons, which show the current status of the collector—protection on, protection
off, degraded, or isolation mode. These icons may be helpful for troubleshooting purposes.
You can also show the user a pop-up notification that appears when a process has been blocked by the
FortiEDR security policies. You can customize the text shown in the notification. For example, some
customers may choose to include information about how to contact the help desk.
If you are running a multi-tenancy environment, note that user notifications are configured for each
organization.
FortiEDR 4.2 Study Guide
55
Administration
DO NOT REPRINT
© FORTINET
Administrators can find and delete personal data for any user on the Tools panel of the Administration tab
under Personal Data Handling. To find all of a specific user’s data, search by device name, IP address, MAC
address, and user name, and delete the results for each search. There may be data associated with the
user’s IP address, for example, that did not come up in a search for the user name. So to be fully GDPR
compliant, you must search for all addresses and names associated with the user.
To comply with GDPR, no record can be kept of personal data, including its removal, if the user requests that
their data be deleted. As a result, if an administrator deletes a user’s data, there is no record of that action in
the audit trail.
FortiEDR 4.2 Study Guide
56
Administration
DO NOT REPRINT
© FORTINET
If you need to uninstall a collector, you can do so remotely from the Inventory tab of the management
console. Please note that you can remotely uninstall a device only when it is connected. You can also
manually uninstall the collector from the device itself. You will need the registration password to manually
uninstall the collector. You learned about the registration password in the previous lesson. You can retrieve it
from the Tools panel of the Administration tab.
Deleting a collector removes it from the management console. You can delete a collector even while it is
disconnected. However, please note that if you delete a collector without uninstalling, it will reappear on your
Inventory tab if the device connects to your network again.
FortiEDR 4.2 Study Guide
57
Administration
DO NOT REPRINT
© FORTINET
In FortiEDR version 4.1.1 and later, you can view IoT devices, like printers, smartphones, or media players,
that have connected to your network. You can scan for devices on the Administration tab of the
management console. Choose Tools, and you’ll see IoT Device Discovery options. Select the Perform
ongoing device discovery checkbox to enable continuous monitoring for IoT devices. FortiEDR uses the
existing collectors in your network to probe for neighboring devices. You can exclude specific collector groups,
if desired. You can also do an ad hoc discovery if needed.
Discovered devices are listed in the Inventory tab under IoT Devices. For each device, you can see the
device name, category (media device, mobile, and so on), model, internal IP address, MAC address, location,
and first and last dates the device was seen. If a device was discovered in the past three days, it will be
marked as New, so you can quickly identify new devices that may need to be reviewed. Devices that have not
been seen in the last week are marked as Expired.
You can enable auto-grouping by device type in the IoT Device Discovery area where you configure device
scans. If you do not select this option, all devices will go into the default group. You can also create new
groups and move devices as needed.
Please note that all IoT device detection, viewing, and organizing capabilities require a Predict and Protect
or Predict, Protect, and Response license.
FortiEDR 4.2 Study Guide
58
Administration
DO NOT REPRINT
© FORTINET
To maintain your system health, you’ll need to keep track of your license permissions and capacity. In the
Administration tab under Licensing, you’ll see your license type listed, along with the features available with
that license. The example on this slide shows a Predict, Protect and Response license, and all the FortiEDR
features are available.
You can also see information about your license usage. There are three types of license seats. Workstations
cover most of your end users. Server licenses apply to any collector installed on a server, including all Linux
versions. On the right, you can see a visual representation of the license seats in use and those remaining for
workstations and servers. In the example shown on this slide, 11 workstation seats have been used and eight
are remaining. All four server seats have also been used. IoT devices include all non-workstation devices
connected to your network, such as printers, smart phones, or media players. You can see all 10 IoT seats
have been used. If you need more license seats, contact Fortinet support to extend your license capacity.
You’ll also need to be aware of your license expiration date. You can see the expiration date at the top of the
window. If your expiration date is approaching, contact Fortinet support to update your license.
When you renew or extend your license, you’ll get a new license string. To update your management console,
click Update License and paste the string into the window.
FortiEDR 4.2 Study Guide
59
Administration
DO NOT REPRINT
© FORTINET
System events are events that affect the protection of user devices. For example, when the core is down, the
aggregator is down, or collectors are turned off or turned on. Adding a new collector also generates a system
event. Licensing issues are also tracked in system events—for example, when a license is close to its
expiration date (21, 7, or 0 days) or close to the license capacity.
It’s very easy to manage system events. they trigger real-time notifications through any configured email or
syslog output, or you can export the events to Excel or PDF.
FortiEDR 4.2 Study Guide
60
Administration
DO NOT REPRINT
© FORTINET
There are two ways to configure system event notifications. You can configure one or both. The first method is
email notifications. To enable email notifications, click the Administration tab on the management console
and click Export Settings. Here, you can enter standard SMTP settings to enable email notifications. Be
careful with these—if you delete or accidentally alter them, all your email alerts will be disabled.
After you’ve got your SMTP settings configured, click Distribution Lists in the left-hand list to configure your
email distribution list. Your FortiEDR installation comes preconfigured with an All Recipients list. You cannot
configure notifications for this list, so you will need to create a new list by clicking the Create List button. With
your new list highlighted, check the Notifications area to the right. Make sure that System Events is
enabled. You may choose to include Security Events as well—events that violated FortiEDR security
policies—or set Security Events to Disabled, if you don’t want to send them to this list. You will learn more
about security event notifications in a later lesson.
After you’ve set up your list, click Add Recipient and enter the first name, last name, and email for your first
recipient. New recipients are added to the All Recipients list. Select the checkbox next to the recipient or
recipients you want to include in your list and click Assign to List to add them to your custom list.
FortiEDR 4.2 Study Guide
61
Administration
DO NOT REPRINT
© FORTINET
You can also choose to send system event notifications through syslog. Configure syslog on the
Administration tab of the management console under Export Settings. If your syslog parameters have not
been added, click Define New Syslog and enter standard syslog parameters. You can send messages over
TCP or UDP, choose your port, and enable SSL. Use comma-delimited rather than name-value pairs. When
you’ve entered your parameters, click Test to verify, then click Save. Highlight your syslog and check the
Notifications pane on the right. Make sure System Events are enabled. You may also choose to include
notifications about security events or the audit trail.
FortiEDR 4.2 Study Guide
62
Administration
DO NOT REPRINT
© FORTINET
FortiEDR version 4.1.1 and higher can be configured to integrate with FortiGate, allowing you to automatically
block malicious IP addresses detected in security events or automatically send malicious files to FortiSandbox
for analysis. You can configure your integration using RESTful API or on the Administration tab of the
management console under Integrations. Be aware that you also need to configure FortiGate and
FortiSandbox to integrate with FortiEDR. Detailed instructions are available in the FortiEDR Fabric Integration
Guide and the FortiEDR Installation and Administration Guide. To configure your integrations, you will need
an on-premises core and a valid API user able to access FortiGate and/or FortiSandbox. You’ll also need a
central manager that is connected to Fortinet Cloud Service.
FortiEDR 4.2 Study Guide
63
Administration
DO NOT REPRINT
© FORTINET
To integrate FortiEDR with your FortiGate installation, start by configuring FortiGate. In the left-hand menu,
click to expand Policy & Objects, then select Addresses. Create a new address group. FortiEDR will
populate this group with malicious IP addresses involved in security events. Next, click on IPv4 Policy in the
left-hand menu under Policy & Objects. Create a new policy to deny traffic to any addresses in the address
group you just created.
Next, you’ll need to configure the connector in the FortiEDR management console. On the Administration
tab, click Integrations. Click Add Connector and choose Firewall from the drop-down list. Choose a core to
communicate with FortiGate. Note that you must have an on-premises core to configure a connector. Add a
name to identify the firewall, then enter the firewall’s IP or DNS address, port, API key or credentials, and the
address group you created in FortiGate.
Once your connector is configured, the last step is configuring your playbooks to automatically send malicious
IP addresses to FortiGate. Under Security Settings, choose Playbooks. For each playbook you want to
configure, find the Block address on Firewall rule in the Remediation section. Select your configured
firewall—the name here is the name you entered when configuring the connector earlier. Lastly, choose which
event classifications will trigger this action. Next time an event with one of the selected classifications occurs,
you should see in the Event Details that the malicious IP address has been sent to FortiGate.
If you prefer to use the API, you can find detailed instructions in the FortiEDR Fabric Integration Guide.
FortiEDR 4.2 Study Guide
64
Administration
DO NOT REPRINT
© FORTINET
You can also configure a connector with your FortiSandbox installation.
First, set up the connector in the FortiEDR management console. On the Administration tab, select
Integrations. Click Add Connector and choose Sandbox from the drop-down list. Select the on-premises
core you want to communicate with FortiSandbox. Enter a name for the sandbox, then enter its IP or DNS
address, the port, and the API key or credentials to access it.
Next, you’ll need to configure your security policies to enforce the sandbox analysis rule. This is one of the
few rules that are set to Disabled by default. Under Security Settings, choose Security Policies. Locate the
execution prevention policy and click to view its rules. You should see the sandbox analysis rule. It should be
grayed out, and the icon in the state column should say Disabled. Click the Enabled or Disabled icon to
toggle the state to Enabled. If you have clones of the execution prevention policy, repeat these steps for
them. Now if an event violates the sandbox analysis rule, the file will automatically be sent to FortiSandbox for
analysis.
You can find detailed instructions in the FortiEDR Fabric Integration Guide.
FortiEDR 4.2 Study Guide
65
Administration
DO NOT REPRINT
© FORTINET
Now you’ll learn about management console users. You can find a list of your organization’s management
console users on the Administration tab under users. There are four levels of permission. The default level is
user. A user can view and edit information for their organization on every tab of the management console
except Administration. That tab is hidden to them.
Next you have admins. Admins can view and edit information anywhere on the management console. Local
admins exist only for multi-tenant environments. Local admins have the same permissions as admins, but
only within their organization. All other organizations are hidden to them. You’ll learn more about multitenancy in a later lesson.
A user must have rest API permissions to access the management console through API. Rest API users
generally also have user or admin permissions.
There are three ways to create management console users. The first is manually, under Local Users. These
users are created and managed individually through the management console. You can also use LDAP
authentication to authenticate users and assign permissions based on existing LDAP users. Be aware that
LDAP requires a local core with access to the LDAP server. Lastly, you can connect to a third-party identity
provider to authenticate users using SAML authentication.
FortiEDR 4.2 Study Guide
66
Administration
DO NOT REPRINT
© FORTINET
When you create management console users manually, you have the option to enable two-factor
authentication. Just click Edit next to a user, and in User Details, select Require two factor authentication
for this user, then click Save. You can also enable two-factor authentication when you’re creating a new
user.
Click Reset password in the user list to reset the user’s token or password. If you are using LDAP
authentication, open the LDAP Authentication panel and select Require two-factor authentication for all
LDAP logins.
FortiEDR 4.2 Study Guide
67
Administration
DO NOT REPRINT
© FORTINET
FortiEDR two-factor authentication works with any standard authenticator app. Install an authenticator app on
your smartphone if you don’t already have one. On the login screen of the console, type your username and
password, and your organization name, if you’re in a multi-tenant environment. You’ll see a QR code like the
one in the center. Scan it with your authenticator app on your phone. This will associate a specific token
generated in the app with your FortiEDR login. Enter the token generated by the app to complete the setup
process.
After you’ve set up your two-factor authentication, the next time you log in will be the same as usual. You will
enter your name and password—and organization name if applicable—and log in. You will be required to
enter a new token once every seven days. When you see the authentication screen on the right, repeat step
4, and you’ll be set for the next week.
FortiEDR 4.2 Study Guide
68
Administration
DO NOT REPRINT
© FORTINET
You can generate an audit trail to keep track of user actions on the management console. Every user action in
the management console is logged—user logins, changes to an event status, viewing events in Forensics,
and so on. On the Administration tab, select Tools from the menu on the left and you’ll see Audit Trail.
Choose a date range and click Generate Audit. You can download a CSV file to your local machine showing
the date, sub-system, user, and a description of each action. You can also send the audit trail to your SIEM
solution through syslog. `
FortiEDR 4.2 Study Guide
69
Administration
DO NOT REPRINT
© FORTINET
As of version 4.1.1, you can customize the look and feel of the FortiEDR management console. When you’re
logged in as the support user, you’ll see Customize in the menu on the left-hand side of the Administration
tab. Click Download Template Theme or Download Current Active Theme to save a zip file to your hard
drive. The zip file contains a set of images used on the GUI, such as logos, backgrounds, and headers. You’ll
also find a properties file and a CSS file. Replace and revise the files as needed, then click Upload custom
theme to import your own branding template. If you change your mind, you can always click the Restore
Default Theme button to restore the original Fortinet look and feel.
FortiEDR 4.2 Study Guide
70
Administration
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
71
Administration
DO NOT REPRINT
© FORTINET
This slide shows the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to configure key elements of your
deployment.
FortiEDR 4.2 Study Guide
72
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
In this lesson, you will learn best practices and how to conduct a successful FortiEDR deployment.
FortiEDR 4.2 Study Guide
73
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in best practices and deployment, you will be able to manage a successful
FortiEDR deployment.
FortiEDR 4.2 Study Guide
74
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
A best practice is a method or technique that is generally accepted as either superior to alternatives because
it produces better results, or that has become the standard way of doing things. Many regulatory schemes talk
about best practices. CISSP requires due care and due diligence. Due care is taking responsibility for
security, and due diligence is a way of delivering that care and ensuring that controls are monitored and
updated. Gross negligence is the opposite of due care. When you’re deploying and working with the FortiEDR
product, we want to make sure that you avoid gross negligence by following best practices. Common
examples of best practices include the separation of duties, disaster recovery planning, and change control
policies.
FortiEDR 4.2 Study Guide
75
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
So why should you follow best practices? The first reason is that Fortinet is very customer success focused.
Fortinet is constantly deploying around the globe across many different industries, which offers visibility into
any potential challenges. Fortinet stays in close contact with the customer, and continuously improves the
platform based on customer feedback. This feedback is integrated into best practices, so you can get the
most out of FortiEDR. Following best practices also minimizes confusion. If you’ve got a custom installation
method or you're not following best practices, then you have to take some time to go back and explain your
process to whoever you're working with, and it can cause surprise or confusion. The next reason for using
best practices is that they’re well-defined and repeatable. Following an established process through multiple
deployments allows the process to become more refined, and increases efficiency over time.
FortiEDR 4.2 Study Guide
76
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
Fortinet doesn't break down project deployment phases into a complicated scheme. There are
three phases. The first phase is a new project. This phase includes planning, assigning project
members, deciding on the project schedule, and holding a project kickoff meeting.
After you have completed the planning and project kickoff, you move into the second phase: the
actual deployment and tuning. This is where you start deploying the waves. During deployment,
monitor the events and set exceptions or mitigate malware. Hold periodic project review meetings
to track your progress. After you reach a predefined goal—for example, 4,000 seats deployed—you
will move into the daily operations phase: monitoring alerts, responding to malware, and creating
the exceptions. Any new project requires a new project entry, or project reopening. You will learn
more about that later in this lesson.
FortiEDR 4.2 Study Guide
77
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
Projects have a very clearly defined beginning and end. An end point is not always an absolute. For example,
if a customer has 5,000 seats, the project might end when 3,000 or 4,000 of the 5,000 endpoints are
deployed. Fortinet gets them started, then once the customer knows the process, they can complete the
deployment on their own. During the project startup phase, you will set well-defined criteria for moving
between phases. The criteria might be a percent deployment or a set number of seats deployed. For example,
the criteria might be that when the project reaches 3,000 seats deployed, the customer will start managing the
deployment process.
The next point to note is that the move to operating in protection mode does not happen all at the completion
of deployment. The move to protection mode should take place in parallel with the deployment. For example,
deploy 150 seats, then two weeks later move those 150 collectors into protection mode, and so on. That
makes the transition a lot smoother, because it’s easier for the customers and the partners to monitor how the
transition is going.
Reentry into a project requires a restart. For example, if a customer takes over the deployment before it is
complete and then finds they cannot complete the deployment on their own, a new engagement and a project
restart would be required for a Fortinet project team to return and help complete the deployment.
FortiEDR 4.2 Study Guide
78
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
The role of the partner in the deployment process depends on the type of partner. Fortinet groups
partners into two broad categories. The first category is a traditional reseller model: Fortinet sells
to the end customer, responds to the alerts, and sets exceptions, provided that the customer
purchases an alert management subscription. If they don't purchase a subscription, then the
customer responds to alerts themselves, and Fortinet is available for escalations only. In an MSP
model, the partner sells to the customer. The MSP handles the alerts, sets the exceptions, and
Fortinet is available for escalations, typically purchased as a bucket of hours.
FortiEDR 4.2 Study Guide
79
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
Now you will learn about how FortiEDR deployments are structured. All FortiEDR deployments are
done in waves. All collectors start in simulation mode, and then are moved to protection mode
after tuning. Collectors should be monitored following deployment, and any process that causes a
simulated block should be reviewed, and either an appropriate exception set or the malware
remediated.
The best way to structure your deployment is to start small and wide. Customers often want to
deploy on a few IT devices first. This is a great start, but you should move to a wider deployment
across multiple business functions as part of the first deployment group. That way, you are more
likely to encounter any potential issues early in the process, and see fewer issues later.
FortiEDR 4.2 Study Guide
80
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
So how do you plan a deployment? To involve Fortinet in a new deployment, you need to submit a
request so that Fortinet can ensure that there are enough resources in place to cover you.
Deployments are broken into waves of progressively more collectors. For a 5,000 seat deployment,
you may have an initial rollout group of 150, then 300, 750, 1,500, and so on. The size of the
deployment waves needs to be small enough that any potential issues don't overwhelm your
resources, but large enough so the deployment happens at an appropriate pace. Again, as you
move through the deployment, your waves can get progressively bigger. Keep track of your
deployment through regularly scheduled meetings.
FortiEDR 4.2 Study Guide
81
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
On this slide, you will learn about network capacity planning. Traffic needs to flow from collectors to cores and
aggregators, so it’s important to have enough capacity to handle that traffic. FortiEDR can generally run off
one cloud-based core, but in some cases, organizations may choose to add additional cores to optimize
performance. Global companies typically have a core in each cloud zone: Americas, Europe, and Asia Pacific.
You can also deploy multiple local cores, as needed. During the deployment process, you should check the
network for slow links that may cause bottlenecks. In a large deployment, you’ll need site lists and internal
subnets.
This slide details two example deployments. In the first example, the company is covering 4,000 collectors
globally. They will need a cloud-based core in each cloud zone and local cores at each major data center. In
this example, the company also has an office in New Zealand with a slow WAN link, so they have decided to
add a local core in that office. The second example is smaller company based in the US. Their deployment is
400 seats. One core is more than capable of handling 400 collectors; however, in this company, there are
many employees travelling to China. So, two cloud-based cores have been added—one in the Americas and
one in Asia-Pacific—as well as a local core onsite at the company headquarters.
FortiEDR 4.2 Study Guide
82
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
As you are planning your deployment, you will want to think about how to organize your collectors.
Collectors are organized into groups, which can represent organizational structure, function, or any
other scheme you choose. Security policies are assigned at the collector group level, and each
policy can operate in simulation or protection mode. Assign groups to policies in simulation mode
until they have been tuned, then assign them to policies in protection mode so that FortiEDR
actively protects them from threats. In specialized cases, you could use collector groups to assign
customized policies or set granular exceptions, but best practice is to set exceptions on a global
basis, unless you have a specific reason not to.
There are a couple of groups you should always have. First is a high security collector group.
FortiEDR comes with a built-in high security collector group. This group provides additional
protection to infected collectors until you have fully remediated the devices. The high security
collector group should always be assigned to strict policies in protection mode to protect infected
devices.
You should also create a simulation group for rapid troubleshooting. If you have a machine that you
need to troubleshoot quickly, you can move it into the simulation group to determine whether
FortiEDR is blocking a process. The other collectors in the group can stay where they are and
continue to be protected. When you’re done troubleshooting, you can move the affected machine
back to its original collector group.
FortiEDR 4.2 Study Guide
83
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
When you’re monitoring the rollout, you must have local frontline support involved. You’ll need
onsite assistance—it could be for something as simple as restarting a machine, pulling a file from a
machine, or running a manual install. You need to integrate with the local help desk to make sure
they know basic troubleshooting steps. If there is an issue, you can get hands-on support.
You need to tune the events as they occur. The false positive rate is very low, but you’ll need to
watch for events from newly deployed collectors, and set exceptions as needed to allow safe
processes to run. If you see a malicious event, move the collector to the high security collector
group to protect the infected machine and the rest of your system from further harm. You can also
use isolation mode to contain infections.
If you haven’t seen any events that required tuning in a set time period—typically two weeks—then
you can move that group into protection mode.
FortiEDR 4.2 Study Guide
84
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
To maintain security during deployment, you need to be aware of any malicious events that occur while the
collectors are in simulation mode. There are a couple ways you can contain infections that occur during this
period. The first is moving infected collectors to the high security collector group. Fortinet recommends always
assigning this group to policies in protection mode, even in the tuning phase.
The second is placing infected collectors in isolation mode. Isolation mode is a state—it does not affect
collector group assignment, but the isolated collector is automatically assigned to the Isolation Policy in
communication control, rather than its group policy. By default, this policy blocks all applications from
communicating. In the Communication Control tab, allow specific applications as needed, such as security
software or remediation tools.
Automated incident response, or playbooks, allow you to assign automatic actions based on the severity of
the event. You can use playbooks to contain any infections that occur during deployment. In the example
shown on this slide, when an event is classified as malicious, the affected collector is automatically put into
isolation mode and moved to the High Security Collector Group. Playbooks can be kept in protection mode,
even when security policies are in simulation mode. So, while you’re tuning your deployment, you can
automatically contain any infections.
FortiEDR 4.2 Study Guide
85
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
Continuity of business operations is ultimately the responsibility of the customer. Fortinet can
assist in setting exceptions and managing alerts, but ultimately, the customer is responsible for
maintaining the continuity of business operations. Fortinet can consult with a customer on
maintaining the business, but we rely on the customer to provide insight into which business
functions are crucial and whether or not there's any outage periods. Communication is the key to
reducing risk. The number one cause of project failure is poor communication. Fortinet addresses
continuity of business operations by communicating early and often with customers.
FortiEDR 4.2 Study Guide
86
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
Sometimes, changes to best practices are necessary, but they do require prior approval. Here is a
good example of a scenario involving a change to best practices. A customer is hit by malware.
Because of the direct threat, the customer requests a quick two to three-day deployment of 5,000
seats. In a scenario like this, a discussion would take place to determine the best course of action.
Large or fast deployments, the disabling of a large number of policies, or changing the partner or
Fortinet responsibilities are all actions that require prior approval. If a customer decides to manage
the product on their own and cancel their alert monitoring subscription, or if a customer wants to
increase their alert monitoring, both of these requests require changes to best practices. These
changes need to be discussed and approved at a project meeting.
FortiEDR 4.2 Study Guide
87
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
There are three main support teams, each fulfilling a different role. The Fortinet support team
handles break-fix requests. Typical break-fix requests include forgotten passwords and an inability
to access the FortiEDR console.
The Fortinet forensics team offers support related to potential infections. Typical requests sent to
the Fortinet forensics team are: “What does event 1384 mean?”, “Is this malware?”, “What kind of
malware is this?”, and “How did I get this malware?”
Last is frontline helpdesk support. Helpdesk staff need to have a broad base of knowledge, but only
an inch deep. They need to be able to answer questions, such as, “Do I have FortiEDR running?”, “Is
FortiEDR blocking a program?”, “What's happening on my FortiEDR client?”, and “Do I have the
latest version?” This slide shows a basic decision chart for troubleshooting potential FortiEDR
issues. You will learn about this decision process in another lesson.
FortiEDR 4.2 Study Guide
88
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
There are two alert management types for partners. In partner-led management, the partner
monitors the alerts that require analysis, and then they buy a bucket of forensics hours for any
events requiring input from Fortinet forensics. Whenever the partner needs help with a specific
event, they send Fortinet forensics an event, and Fortinet does an analysis.
The other method, typically used more by customers, is an alert management subscription. In this
scenario, Fortinet manages the alerts, and the partner provides risk analysis or context. In both
management type scenarios, either side can escalate at any time.
FortiEDR 4.2 Study Guide
89
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
How are Forensics alert requests processed? With an alert monitoring package, Fortinet sorts the incoming
alerts into high-level categories, and the customer or partner is required to review certain actions. The
categories are malware, which has been verified as malicious; grayware and potentially unwanted apps,
which may be somewhat legitimate; vulnerable apps, which are legitimate but contain vulnerabilities which
may make them look like malware; and confirmed safe software, which Fortinet has set an exception for.
Fortinet is also available to answer questions about specific alerts. If a customer has a special request
requiring a large number of additional resources, the request requires additional scoping and negotiation.
Without the alert monitoring package, the customer or the partner identifies alerts that require more analysis,
and Fortinet then bills hourly.
FortiEDR 4.2 Study Guide
90
Best Practices and Deployment
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
91
Best Practices and Deployment
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 use the best practices for a successful
FortiEDR deployment.
FortiEDR 4.2 Study Guide
92
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
In this lesson, you will review the basics and functions of the FortiEDR management console.
FortiEDR 4.2 Study Guide
93
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in navigating the user interface, you will be able to perform day-to-day tasks on
the FortiEDR management console.
FortiEDR 4.2 Study Guide
94
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The FortiEDR management console is divided into seven tabs. Your current tab is underlined in green, which,
in the example shown on this slide, is the Dashboard. The Dashboard tab provides a general overview of
system security and health.
The Event Viewer tab is where you can monitor and handle security events.
The Forensics tab includes two sub-tabs. The first sub-tab, Events, shows you detailed information about the
exact processes involved in a security event. You can load events from the Event Viewer into the Forensics
tab to analyze them in depth. The second sub-tab is Threat Hunting. Here, you can search for malware
across your entire environment. You can search by hash or filename.
The next tab is Communication Control. Again, this tab has two sub-tabs. Under Applications, you can see
a list of the applications that are communicating on the network. It doesn't display all the applications that are
installed, just the ones that are communicating. Communicating applications present the most risk. On the
Policies sub-tab, you can configure rules to decide which applications and versions can communicate over
your network.
On the Security Settings tab, you can view and manage the security policies on the Policies sub-tab. You
can change modes, clone policies, assign policies, and disable or enable individual rules or change their
assigned action. Playbooks are also found on the Security Settings tab. Playbooks control event notifications
as well as optional investigation and remediation steps.
On the Inventory tab, you can view network components. On the Collectors sub-tab, you can see all
collectors in your system and their status. You can also organize them into groups. Under IoT Devices, you
can view all the IoT devices that FortiEDR has detected in your network. System Components shows you
the status of your FortiEDR servers—the core, aggregator, and repository.
The last tab is Administration. Here, you can review and set administrative options for your network,
including licensing, creating console users, LDAP authentication, and more. Administration is the only tab that
is not available for users who don't have administrative rights—the tab is hidden for those users.
FortiEDR 4.2 Study Guide
95
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
This slide shows the dashboard you’ll see every time you start a new session. It has charts that give you a
quick view of your system status, including: unhandled security events and communicating applications, the
most-targeted devices or most common malicious processes, and the health and status of all your system
components. You’ll also see a map showing the location of any IP addresses that were involved in security
events—the addresses the processes tried to connect to.
FortiEDR 4.2 Study Guide
96
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
Start by looking at the Security Events chart. Think of this chart as a to-do list, showing you the number of
unhandled security events in your network. Unhandled events have not been processed. You can group
events by device to see how many devices have unhandled security events, or you can sort by process to see
how many different processes you have that are unhandled. In a well-maintained system, you should see very
few events here.
FortiEDR automatically classifies each event to help you decide how to prioritize them. Event classifications
are color-coded for easy identification. Classifications range from malicious—processes that are known to be
bad—to likely safe—processes that are exhibiting unusual behavior, but are not suspected to be a threat. You
will review event classifications in more detail later in this lesson.
FortiEDR 4.2 Study Guide
97
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The Communication Control chart shows you how many unresolved applications are communicating within
your network. These are applications that no one has reviewed and approved or blocked—either at your
company or at Fortinet. These are not malicious—malware is blocked before it reaches Communication
Control—but you may want to block certain applications from communicating because of vulnerabilities or
company policies. You will learn more about communication control in this lesson. The chart is color coded by
type: light blue indicates unknown and unsigned vendors, green indicates applications with a low reputation
score, and dark blue indicates application versions with critical vulnerabilities.
FortiEDR 4.2 Study Guide
98
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The Most Targeted chart shows the devices or processes that generated the most events. You can view
events grouped by affected device or by the process that caused the alert. Events are color-coded by
classification. It’s a quick way to identify current active threats or vulnerable devices. If you click a column,
you’ll see the Event Viewer tab filtered to show you the events involving the selected process or device. In
this case, if you wanted to know what events were affecting the second desktop device, you could click the
column total, and it would take you right to the events for that device.
FortiEDR 4.2 Study Guide
99
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
This slide shows the External Destinations map. The map shows the locations involved in security events
over the past day, week, or month. Zoom in to view specific regions. Hover over a location marker to view the
specific IP address or addresses, and click on the marker to view the associated events on the Event Viewer
tab.
FortiEDR 4.2 Study Guide
100
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The Health Charts show you the status of the system components. On the Collectors chart, you can view
collectors grouped by status—the General view—by version, or by operating system. You can click any
column to view the components on the Inventory tab. For example, if you see that there's a large number of
machines that are running an older version of the collector, you can click the version column and view all the
machines running the outdated version.
The System Components chart shows you the current status of all your server and cloud components—
cores, aggregators, Fortinet Cloud Services (FCS) and if applicable, the threat hunting repository. This is a
quick way to check that all your components are up and running.
FortiEDR 4.2 Study Guide
101
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
From the dashboard, you can also generate an executive report. On the dashboard, click Generate Report
and choose a time period for which to generate a PDF-based executive report. The report will include overall
event statistics, destinations, most targeted devices, and most common processes for the specified time
period. It also includes a list of new communicating applications, the most blocked application for each
communication control policy, system components, and license status. It’s a great way to show your
management team a very high-level view of what has been happening in your network.
FortiEDR 4.2 Study Guide
102
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The Events pane allows you to sort, browse, and search events. Events are aggregated into alerts. They can
be aggregated by device or process, depending on the setting you choose. In the example on this slide,
events are aggregated by process, so each alert contains all the events related to a particular process. There
are 21 events related to G2MCommonResources.dll. The first event is highlighted in green. In the
Advanced Data section, the process flow diagram for the highlighted event is displayed. If you click the Geo
Location link in the Advanced Data section, you will see a destination map showing destinations linked to
this one event. If this map is unavailable, that means that the event did not involve external communication.
The Classification Details pane shows the details for the highlighted process. You can see the current
classification, along with any other information about the threat family, type, and so on. You can also see the
classification history. This shows whether the classification was made by the FortiEDR core, FCS, or a
console user, along with any previous classifications assigned to the event and when they were changed.
Below the classification history, you can see the rules that were triggered. You can see each rule that was
triggered, what policy the rule belongs to, and a definition of the rule. This information gives you a good idea
of what happened and what you should do next.
FortiEDR 4.2 Study Guide
103
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
This slide provides a closer look at the Events pane. You can aggregate events by process or device. In the
example shown on this slide, events are aggregated by process. Click any alert to view the events associated
with that process or device, then click an event row to see more details about the event.
For each event, you’ll see the unique ID number, the Device name, the Process that triggered the event, the
assigned Classification, and the event Destinations. If the event tried to connect to more than one
destination, you’ll see the number of destinations listed in this column. Then, you’ll see the date the event was
first seen—the Received date—and the most recent occurrence—the Last Updated date.
At the far right of each event row, you’ll see the action performed in response to each event. FortiEDR either
blocked it, logged it, or simulated a block. That means it would have been blocked, but the policy was in
simulation mode. The action is determined by the violated rule.
You’ll also see an arrow at the left side of the event row. You can click that arrow to view raw event details.
Each event can have one raw event or many—for example, a process that attempts to connect to multiple IP
addresses could have many raw events.
FortiEDR 4.2 Study Guide
104
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
It’s important to understand the two ways of selecting events. The first is highlighting. When you click an
event, it’s highlighted in green. You can see on this slide that the first of three events involving a process
called srm.exe is highlighted. The highlighted event is expanded to show additional details in a second row.
More information about the highlighted event is shown on the Advanced Data and Classification Details
panes. You can only highlight one event at a time.
The second way to select an item is to select its checkbox. Checked items are independent of highlighted
items. In the example on this slide, the event involving srm.exe is highlighted and the checkbox is selected
for an event involving a process called RMActivate.exe. Selecting the checkbox for an event activates the
buttons at the top of the pane. You can archive it, mark it as read or unread, mark it as handled, delete it, or
view detailed information in Forensics. You can also export checked events to a PDF or Excel document.
Unlike highlighting, you can select multiple checkboxes at the same time. Select an alert’s checkbox to select
all the events in that alert, or select the checkbox at the top of the column to select all the events.
FortiEDR 4.2 Study Guide
105
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The details shown apply to the event that is highlighted in the events list. Each event is automatically
classified as malicious, suspicious, inconclusive, potentially unwanted program (PUP), or likely safe. In the
example on this slide, you can see the threat classification—Malicious—as well as the threat name, threat
family, and threat type, if available. The History section shows any previous classifications assigned to the
event. The FortiEDR core assigns the classification. In this example, the core classified the event as
suspicious. You can modify based on further analysis either by FCS or a management console user. In this
example, FCS did some further analysis and reclassified the event as malicious. You’ll also see any
automated actions applied to the affected device based on its classification. These examples are carried out
by playbooks, based on the FCS classification.
Lastly, you can see the rules that this event triggered and which policy they belong to. In this example, an
execution prevention policy recognized the file as suspicious.
FortiEDR 4.2 Study Guide
106
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
The Classification Details pane includes information about the triggered rules—the rule or rules that were
violated. Each rule has an assigned action of log or block. You can see an indicator next to the rule at the
bottom of the Classification Details pane. This action determines the action taken by FortiEDR. If more than
one rule is triggered, the most serious rule violation determines the action taken. In other words, if any of the
violated rules are set to block, the event is blocked. In this example, the suspicious file detected rule has an
assigned action of block.
The action taken is also shown in the event row. A red oval means that the event was blocked, and the page
icon means the event was only logged. The gray oval means that the rule’s assigned action was block, but the
policy was in simulation mode. FortiEDR would have blocked the event if the policy had been in protection
mode. You can also see the action taken in the process flow diagram under Advanced Data. In the example,
you can see that the event was blocked.
FortiEDR 4.2 Study Guide
107
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
How can you find an event or set of events? You can use filters to help you prioritize. The drop-down list in the
upper left that contains options in red text is the filter. In the example shown on this slide, Unhandled is
selected from the drop-down list. This is the default selection. Unhandled events are the events you need to
investigate and respond to. There are several options available in the filter drop-down list. You can select a
filter based on what you are searching for. You can also sort events by column header. If you have more than
17 alerts in the selected view, use the arrows at the top to browse.
You can also search for events by typing a search term in the search bar. If you click the down arrow inside
the search bar, you can search using a combination of criteria, such as collector, collector group, process,
date, classification, and so on. If you want to see the full list again, click the X inside the search field.
FortiEDR 4.2 Study Guide
108
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
To keep your environment organized, it’s important to update the status of events as you work. The most
important statuses are handled or unhandled. Marking an event as handled means it’s off your to-do list. You
or another management console user analyzed the event and remediated or created an exception as needed.
When you are ready to mark an event as handled, select its checkbox, then click Handle Event to open the
Event Handling window shown on this slide. You can use the comment box to record an explanation of how
you handled the event, then click Save as Handled. The event flag turns white, and if the event list filter is set
to show just unhandled events, you’ll no longer see the event.
In the Event Handling window under Advanced, you’ll also see the Mute event notifications option. Active
threats can be very noisy, so if you are in the process of remediating a threat, you may want to select this
option. Further instances of the event will still be blocked or logged, and you will still see them in the
management console, but notifications for the selected event will be suppressed. You can select a time
period, and click Save to preserve your changes without marking the event as handled. You should mark an
event as handled only when you are finished dealing with it. Notifications will resume after the selected time
period.
FortiEDR 4.2 Study Guide
109
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
Another way of indicating event status is by marking it as read or unread. When you click on an event row,
that event is automatically marked as read. An alert is marked as read if all its events are read. Read events
are shown in plain text, unread events are bold.
You can manually mark an event as read or unread. For example, you might revert an event status to unread
if you want somebody else to look at it. Select the event checkbox, click Mark as… and select Read or
Unread.
FortiEDR 4.2 Study Guide
110
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
You can select events from the Event Viewer tab to view on the Forensics tab, where you can analyze them
in depth. Select the checkbox for one or more events, then click the Forensics button. The event is loaded
onto the Forensics tab. Make sure you click the Forensics button, not the Forensics tab. If you click the
Forensics tab, it will open without loading the selected events.
If you want to add events, go back to the Event Viewer tab and repeat the same steps. You’ll see a fingerprint
next to the events that are already loaded in Forensics. Click the Forensics button again to add your new
selections to the events you’ve already loaded.
FortiEDR 4.2 Study Guide
111
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
After you load events into Forensics, you have two viewing options. The default view is the Flow Analyzer
view, which is shown in the example on this slide. In this view, you’ll see a graphic representation of the steps
involved in the event. Click the Flow Analyzer view button to select this view. You can also select the Stacks
view, which shows detailed information about each stack and its sub-processes. Click the Stacks view button
to select this view, or click a node on the Flow Analyzer chart to view its stack in the Stacks view.
You can load more than one event at a time onto the Forensics tab. Each event on the Forensics tab gets its
own subtab that you can click to view the event. You can also click the Compare View button to view two
events side by side in a split screen.
Rendering events on the Forensics tab can use a lot of resources. If you load a lot of events, it can cause the
screen to slow down. You can clear individual events from the Forensics tab by clicking the X in an event
subtab. You can also click Clear All to empty the tab completely and start fresh.
FortiEDR 4.2 Study Guide
112
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
A single event may be made up of one raw event or many raw events. The raw event data is shown on the
upper portion of the Forensics tab. You can use the arrows on the upper-right of the pane to browse through
each raw data item. If you want to focus on specific raw events, you can click Select raw data items, then
select the checkboxes for each raw event you want to see. You can click All data items to restore the hidden
raw events.
FortiEDR 4.2 Study Guide
113
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
When you first load an event onto the Forensics tab, you’ll see the Flow Analyzer view. The process flow
diagram for the selected raw event is similar to the one shown in the Event Viewer tab. Each node represents
a process, flow, or service involved in the selected raw event. The white rectangles represent an operation
performed. For example, in the event shown on this slide, you can see that the process explorer.exe
created the process WinWord.exe. The series of events shown in this example generally means that the
user launched the process—Microsoft Word, in this case. As you continue to examine the sample, you will
see WinWord.exe attempting to create the process powershell.exe. PowerShell is a legitimate Windows
program, but it is not generally launched by Word. The PowerShell process then attempts to connect to the IP
address shown, but FortiEDR blocks the connection because it violated the suspicious application rule. You
can click any of these elements to see details in the Stacks view.
FortiEDR 4.2 Study Guide
114
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
Here’s an example of the Stacks view. You can click each stack in the stacks toolbar to see all the collected
data for that stack. Red dots indicate where a violation occurred, so you can quickly find the source of the
problem. For example, in the stacks toolbar, you can see that the violation was in the Connection stack. The
selected stack name is shown in red—in this case, the Connection stack. You’ll see all the collected details
for the selected stack below the stacks toolbar. You’ll learn more about the stacks details next.
FortiEDR 4.2 Study Guide
115
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
Details about the main process of the selected stack—the file name, the publisher, and so on—as well as the
main process hash, are shown on the pane. Click the three vertical dots next to the process hash. You can
select to look up the hash on VirusTotal. VirusTotal is a useful investigation tool. It shows you how other
prominent security programs have classified a file—malicious or safe—and the name assigned to the threat
represented by the file. Clicking the three dots also gives you the option to search for the hash in the Threat
Hunting tab.
You will also be able to see a list of every subprocess in the stack and its details. The number of
subprocesses you see depends on the stack. There is a red dot next to the first executable in the list, which
indicates that a rule violation occurred there. Click a subprocess to view more information. Each subprocess
has its own hash, which you can look up in VirusTotal or Threat Hunting.
FortiEDR 4.2 Study Guide
116
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
When you are investigating a hash in the Stacks view, you also have the option to search for it in the Threat
Hunting module, which is inside the Forensics tab. Threat hunting allows you to search for an executable on
every device in your FortiEDR installation, either by filename or by hash. You can see the first date the file
appeared. In the example shown on this slide, it was seen on October 19, 2018. Because that is the earliest
date, this is probably patient zero. You can delete the executable right from the threat hunting module, as long
as the device is connected. Select the checkboxes, then click Remediate. Be aware that performing
remediation in the Threat Hunting module deletes the file from the selected devices. There is also a
Remediate button in the Forensics module, which allows you to stop a process or repair registry keys, as
well as deleting malicious files.
FortiEDR 4.2 Study Guide
117
The User Interface in Depth, Part 1
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
118
The User Interface in Depth, Part 1
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 navigate the user interface and
perform day-to-day tasks on the FortiEDR management console.
FortiEDR 4.2 Study Guide
119
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
In this lesson, you will continue to review the information and functions of the FortiEDR management console.
FortiEDR 4.2 Study Guide
120
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in installation and architecture, you will be able to install FortiEDR components
and configure key elements of your deployment.
FortiEDR 4.2 Study Guide
121
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Communication control contains two sub-tabs: Applications and Policies. On the Applications sub-tab,
you’ll find the applications list. The applications list identifies all applications in your organization that have
communicated externally. If an application has never tried to establish a connection, it won’t show up here.
Click on an application to view all the versions of that application that have communicated from your
environment. For each application and each of its versions, you’ll see the vendor, the reputation score the
vulnerability rating, and the first and last dates it tried to communicate. You’ll learn more about reputation and
vulnerability later in this lesson.
Communication control policies determine whether or not an application can communicate. Each policy has a
pre-set default action of Allow or Deny. You can tell what a policy’s default action is by looking at its icon. A
gray icon means the policy allows communication by default. A white icon means the policy denies
communication by default. In the example to the lower right, you can see that the default rule has an action of
Allow. This policy—the default communication control policy—is one of the three built-in policies. The other
two, the Server and Isolation Policies, have a default action of Deny. These are special cases where higher
security outweighs potential productivity inhibitors. Most policies should have a default action of Allow.
For each policy, you can create exceptions to the default. For example, if the default action is Allow, you can
block individual applications or versions from communicating. Remember, even if an application is set to
Deny, it can still run, it just can’t connect to the internet.
FortiEDR 4.2 Study Guide
122
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now you will take a closer look at the Applications sub-tab. First is the applications list. Click on an
application to view all the versions of that application that have communicated from your environment. You’ll
notice that each version has a reputation score. This score ranges from 1 (known bad) to 5 (known good). An
application’s reputation score reflects the lowest reputation score of its versions. In the example shown on this
slide, you can see that Dropbox has a reputation score of 3, but several of its versions have a reputation score
of 5. This is designed to call your attention to potential issues, and does not necessarily reflect the reliability of
the application as a whole.
Next to the reputation score is the vulnerability rating. Vulnerability ratings are only available if you have a
Predict and Protect or Predict, Protect, and Response license. If there are known vulnerabilities for an
application version, the most severe Common Vulnerabilities and Exposures (CVE) determines the
vulnerability rating. Then the most vulnerable version determines the vulnerability rating of the application. In
this example, Dropbox has a vulnerability rating of high, based on the one version at the top. Again, this is
drawing your attention to a potential problem with a version of this application. It does not mean that all
versions of Dropbox have a high vulnerability rating.
There are many ways to find applications in the list. You can use the status filter to narrow the list to a specific
set of applications—unresolved applications, for example. You can also change the way the applications are
sorted. By default, they’re listed by the first date they were seen communicating. You can click on any column
header to sort by that criteria. For example, you could click the vendor column header to sort alphabetically by
vendor. The applications list only displays 15 applications at a time, so you can use the arrows at the top to
browse through the rest of the list. You can also search the applications list, either by entering the criteria in
the search bar or clicking on the gray arrow on the right side of the search bar to do an advanced search.
FortiEDR 4.2 Study Guide
123
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
On the right side of the Applications sub-tab, you’ll see the Application Details or Version Details panel.
The name of this panel depends on your selection. On the right, you can see that Dropbox version 71.4.108 is
highlighted, so you’re seeing the Version Details panel. If you highlight Dropbox and don’t select a specific
version, you’ll see the Application Details panel. You can see the name of the highlighted application and,
when applicable, version, at the top of the panel.
In the Policies section of this panel, you can see the assigned action for your selection in each
communication control policy. In the example, the selected version of Dropbox is allowed in three of the
policies shown and denied in one.
Underneath the policies information is the Vulnerabilities panel. If the highlighted version has known CVEs,
you’ll see them listed here. If there are no known vulnerabilities or you have selected an application but not a
specific version, you won’t see this panel.
At the bottom of the screen, you’ll see the Advanced Data panel. Here you’ll see a brief description of the
application, first and last connection times, details about which users attempted to communicate with the
highlighted application or version, and the destination contacted.
FortiEDR 4.2 Study Guide
124
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now look at the Policies sub-tab. The main feature of this screen is the Policies Settings. Highlight a policy
in the list to view its rules. Configure rules to automatically deny communication from current and future
applications based on reputation, vulnerability, or vendor. For example, you could choose to block any
application version with a reputation score of 1 or 2. Console users can also manually allow or block
applications or versions as needed. So, if an application has a reputation score of 3, but it’s on your
company’s block list, you can set it to Deny.
Remember that some policies, like the Isolation Policy, have a default action of Deny. These policies are the
opposite of most policies—you need to create exceptions to allow communication from an application. You will
learn about communication control policies in more detail in a later lesson.
Communication control policies are assigned at the collector group level. Each collector group is assigned to
one policy. By default, it’s the built-in default communication control policy. A policy can have as many groups
assigned to it as you want. Applications are allowed or denied per policy, so an application may be allowed to
communicate in one policy but denied in another. For example, you might apply stricter rules to a policy
assigned to your HR department because they handle sensitive data. Again, Fortinet strongly recommends
allowing communication by default for all client policies.
FortiEDR 4.2 Study Guide
125
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
In Security Settings, you’ll find two sub-tabs. The first is Security Policies. This is a very important tab—it
lists all the security policies in your system and their associated rules. Click a policy to view its rules. FortiEDR
comes preconfigured with one of each type of security policy: execution prevention, ransomware prevention,
exfiltration prevention, and device control. Policies that are defined out of the box by Fortinet are marked with
the Fortinet logo.
In the example shown on this slide, you can see the assigned collector groups for the highlighted policy. The
built-in execution prevention policy is highlighted, and you can see several groups are assigned to it, including
the default collector group. For full protection, each collector group should be assigned to one execution
prevention, one ransomware prevention, and one exfiltration prevention policy.
At the bottom of the tab is Advanced Policy and Rule Data for the highlighted policy and rule. If it’s
collapsed, click the white arrow to expand the pane. First are the Rule Details—you’ll see a brief description
of the rule, and Fortinet’s recommendations for handling an event that violated that rule. Click Factory
Settings to reset the selected policy to its initial state.
FortiEDR 4.2 Study Guide
126
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Take a closer look at the Security Policies pane. Again, you can see the type of policies—Execution
Prevention, Exfiltration Prevention, Ransomware Prevention, and Device Control. Each policy is set to
protection mode—the green slider—or simulation mode—the gray and white slider. Protection mode means
the policy is being actively enforced, so devices assigned to that policy are protected. Simulation mode means
you’ll get a record of events, but FortiEDR is not blocking any processes.
Policies are made up of specific rules, and you can click on a policy row to see the rules. Each rule has an
assigned action that determines what FortiEDR does when a process violates that rule—block the process or
log it. You can change the assigned actions if needed—just click the assigned action to toggle it. Rules can
also be individually disabled if needed, but Fortinet doesn’t recommend this. If you don’t want to enforce a
rule, it’s better to switch its action to Log so you still have visibility into any violations. If you disable a rule,
FortiEDR won’t create any record of events that violate that rule.
FortiEDR 4.2 Study Guide
127
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
As you learned earlier, collector groups are assigned to policies. When you click on a policy to highlight it,
you’ll see the collector groups currently assigned to that policy listed in the Assigned Collector Groups pane
on the right. You can add collector groups to a policy by selecting the policy’s checkbox and clicking the
Assign Collector Group button. That will open the Collector Group Assignment window, where you can
choose which groups to assign. If the selected group is currently assigned to another policy of the same
type—for example, another execution prevention policy—you will see a warning. Click Yes to remove the
group from its old policy and add it to your selected one. Remember that, for full protection, every collector
group should be assigned to one execution prevention, one exfiltration prevention, and one ransomware
prevention policy. Device control policies are optional. If you are in a high-security environment that requires
restricting USB device access, assign your collector groups to a device control policy as well.
You can clone a policy to create customized copies to apply to different groups. Select the checkbox next to
one of the existing policies and click the Clone button. You can then assign your copy a new name and
customize its settings as needed. In general, you should have two copies of each policy type—one in
protection mode and one in simulation mode. Always assign the high security collector group to the policies in
protection mode. During tuning, this lets us protect collectors in case of an infection. Fortinet recommends
creating a collector group called simulation, which should be assigned to the policies that are in simulation
mode. After initial tuning, when all collectors should be assigned to policies in protection mode, you can
temporarily move individual collectors into the simulation group if needed for troubleshooting.
FortiEDR 4.2 Study Guide
128
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now take a look at the Playbooks sub-tab. Automated incident response, or playbooks, are automated sets of
actions that FortiEDR can carry out automatically after an event. You can send event notifications, protect
infected devices while you investigate, and automatically remediate infections. Choose which actions should
be performed for events based on their classification—for example, you may want to move a collector to the
high security collector group after a malicious event, but not after an inconclusive event. If you’re not sure
what will happen if you assign an action, the Advanced Playbooks Data pane at the bottom of the tab has a
brief description of the highlighted action.
Like security policies, playbooks can also be in either simulation or protection mode. If they’re in simulation
mode, FortiEDR will still send notifications, but it won’t do anything else.
You can clone an existing playbook and then change the settings of the copy. Each collector group should be
assigned to one playbook. You can see which collector groups are assigned to the highlighted playbook by
checking the Assigned Collector Groups pane.
Be aware that some playbook actions require you to configure settings on the Administration tab first. Each
notification type—email, open ticket, or syslog—must be configured, and you’ll need to integrate your firewall.
You’ll learn about notification configuration and firewall integrations later in this lesson.
FortiEDR 4.2 Study Guide
129
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now you will learn about the Inventory tab. All the collectors in your network are listed here, grouped by
collector group. When you load this screen, you’ll only see collectors in a degraded state. This is to draw your
attention to collectors that are not performing correctly and need your attention. Click Show All Collectors to
see all the collectors, organized by collector group. You can also do the same thing by clicking the drop-down
filter at the top left corner of the list and selecting All. You can filter by other states too—for example, you
could use the filter to find collectors in isolation mode. FortiEDR also tracks unmanaged devices—computers
detected in your network that do not have the FortiEDR collector installed. Unprotected devices may put your
network at risk. Choose Unmanaged Devices from the filter to view these devices.
You’ll notice some numbers next to each collector group. This shows you how many collectors you can see in
the current view and the total number of collectors in the group. For example, if you set the filter to show only
collectors that are disabled, you might only see one collector out of the 10 that are in the group.
FortiEDR comes with two built-in collector groups: the default collector group and the high security collector
group. To add new collector groups, click Create Group, then reassign selected the collectors to the new
group clicking Move to Group.
FortiEDR 4.2 Study Guide
130
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Select a collector checkbox to enable buttons at the top of the list—Move to Group, Delete, Enable/Disable,
Isolate, and Uninstall. Many of these buttons let you change the current status of the selected collector. The
Isolate drop-down list lets you put a collector in or out of isolation mode. isolation mode is an additional way
of containing an infection until the device is remediated. The collector is assigned to a special isolation
communication control policy, which blocks communication from all applications by default. You can configure
your playbooks to put infected collectors into isolation mode automatically, or you can control it manually from
here. You’ll see a red icon next to collectors in isolation mode. You’ll learn about isolation mode in more detail
in a later lesson. Please note that the FortiEDR platform does not require isolation mode to protect an infected
device; it is an optional additional security measure.
You also have the ability to disable, delete, or uninstall a collector. Usually, disabling collectors is a temporary
measure for troubleshooting. You can use the same button to enable the collector again. Deleting a collector
removes it from the management console, but doesn’t uninstall it from the user device. The collector will
reappear if the device connects again. If you want to permanently remove a collector, you can uninstall right
from the console. Be aware that you can only uninstall or disable a collector while it is running—if it’s not
currently connected, these buttons will be greyed out and you’ll need to wait until the collector connects again.
You can also uninstall the collector or stop its process manually from the end user machine.
FortiEDR 4.2 Study Guide
131
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
The IoT Devices sub-tab shows you all the IoT devices FortiEDR detected in your network. Remember that
IoT device discovery is only available if you have a Predict and Protect or Predict, Protect, and Response
license. To see IoT devices, you first need to enable IoT Device Discovery on the Administration tab, under
Tools. After FortiEDR scans your network for IoT devices, you’ll see the collected details about each device,
including its name, the device category (printer, network device, webcam, and so on), model, internal IP
address, MAC address, country, and the first and last dates it was seen connecting to the network.
There is a filter at the upper-left corner of the list. You can shown only New, Recently Seen, or Selected
devices. You can organize IoT devices into groups. You can configure automatic device grouping on the
Administration tab or you can create and manage groups manually on the IoT Device sub-tab.
During the scanning process, FortiEDR assigns a category to each device—computer, network device, game
console, media device, telecom, mobile, power device, printer, remote management, security, storage,
terminal, VoIP adapter, VoIP phone, webcam, video device, or other. If necessary, you can manually change
the assigned category by clicking the device’s current category in the list and choosing a new one from the
drop-down list.
You can delete devices from the management console to reduce clutter. However, if the device is detected
again on a future scan, it will reappear in the list.
FortiEDR 4.2 Study Guide
132
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
System Components covers the FortiEDR server components—cores, aggregators, and repositories. Like
the Collectors sub-tab, you’ll only see degraded components by default. Click Show All to see all the cores,
aggregators, or threat hunting repositories. You can also use the drop-down filter at the upper-left corner of
each component list to filter by state—Degraded, Disconnected, Running, or show only Selected
components.
For each component, you’ll see the IP address and current state. Cores and aggregators offer some
additional information and options. For cores, you will also see their name, deployment mode (cloud or onpremises), and version. For aggregators, you will see the name, version, and number of connected collectors.
You can filter the lists by state, or search by name, version, IP or, for cores, deployment mode.
Please note that in a cloud deployment, not all system components will be shown on this tab. In a multi-tenant
environment, tenants will not see shared system components.
FortiEDR 4.2 Study Guide
133
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now take a look at the Administration tab. This tab is only accessible to users with administrator privileges.
It’s made up of a series of panes. On the Licensing pane, you can see details about your license. Your
management server is assigned a unique Installation ID, which is listed at the top of the pane along with the
Name of your company and your license Expiration Date.
Below that, you’ll see your License Status—the type of license you have, what components are available,
and how many seats you have. In this example, there are a total of 200 workstation licenses, 100 server
licenses and 200 IoT devices. That means you can install the FortiEDR collector on 200 workstations and 100
servers, including Linux machines, and you can track up to 200 IoT devices. Note that server licenses apply
only to server machines where the collector is installed. This is separate from server components like the core
and aggregator. You can also see how many of those seats are in use. In this example, 31 workstation
licenses are in use and 169 are available.
If you upgrade your license—for example, to extend the time period, or add more seats—Fortinet will send
you a license string. Click Update License to apply your new license string.
You can also load new content on this pane. Fortinet periodically sends content files, which contain any new
global exceptions—processes that violate a rule, but are safe. Once FortiEDR adds a global exception, you
won’t get alerts for that process again. Content files also contain the latest collector versions. When you get a
new collector version, you can run your own installation script to update your devices, or you can load the
latest content and update collectors through the console. Updates are applied to collector groups. Fortinet
doesn’t recommend updating all your collector groups at once, because this may slow your system. Also,
keep in mind that Windows, Mac, and Linux collectors use different versions, so they need to be updated
separately.
If you are connected to FCS, you can request a custom installer. Click Request Collector Installer and enter
the settings you want to configure in your installer. You can use this installer to streamline new installations.
FortiEDR 4.2 Study Guide
134
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Organizations are an optional feature. Many customers choose not to add organizations, and their
environments operate in single-tenancy mode. In some cases, though, multi-tenancy can be a very useful
option. You can use organizations to divide a large deployment into smaller groups. You can also use
organizations to divide multiple client companies into separate organizations, allowing each client to access
their own company’s information, but without allowing them to access any other company’s information. You
can learn about the multi-tenancy feature in more detail in the Multi-Tenancy lesson. Now, you will review the
Organizations pane. After you add an organization, the multi-tenancy feature is enabled. For each
organization, you’ll need to specify a name, registration password, expiration date, and number of workstation
and server licenses. The number of workstations and servers available is determined by your license with
Fortinet. For example, if you had a 1,000 workstations, you could add four organizations with 250 workstations
allocated to each one. If you added a fifth organization, you would have no more seats available—you’d need
to remove some from another organization or buy more workstation seats from Fortinet. From the
Organizations pane, you can see the license capacity for each organization as well as how many licenses
are in use and how many are available. You’ll also notice the expiration date. Soon-to-expire licenses are
flagged with a clock icon. Expired licenses are shown in red. You can change an organization’s expiration
date or license allocation by clicking Edit in the organization’s row. You can also migrate an organization to a
new environment if needed.
FortiEDR 4.2 Study Guide
135
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Next is the Users pane. First is Local Users. You’ll see a list of local console users here. You can add a user,
edit them, or delete them. Each user is assigned permissions. At the most basic level, you can assign Admin
or User permissions. Users can view and edit everything except the Administration tab—that is hidden to
them. Admins can view and edit everything in the console. Local admins are only available if you’re using the
multi-tenancy feature. Local admins have the same permissions as admins, but only for their assigned
organization. They can’t see any other organizations. Lastly, you have Rest API users, who have permission
to access the console through the application programming interface (API). You will learn more about this in
another lesson.
You can reset a user’s password, and you can turn two-factor authentication on or off for specific users. You
can also reset two-factor authentication for a user if they lose their phone.
FortiEDR 4.2 Study Guide
136
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
You can use pre-existing authentication protocols to manage access to the management console. First, you
can use LDAP authentication. To enable LDAP, select the directory type, and enter the standard LDAP
definitions. Group membership determines which users are administrators, users, or have API permissions.
You can enable two-factor authentication for all users, if desired, for added security. Please note that to use
LDAP authentication, you must have an onsite core with connectivity to your LDAP server.
SAML authentication is also available. FortiEDR acts as a service provider (SP) in this scenario. You can
download the SP data from FortiEDR, then upload that data to your IdP server. Again, you’ll use your existing
SAML groups to assign user permissions.
FortiEDR 4.2 Study Guide
137
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now, you will learn about distribution lists. You can configure distribution lists to specify which users should
receive email notifications about different types of events. You can send system events (system status
changes or updates) or security events. If security events are enabled for a list, the playbook settings
determine what classification levels will trigger an email notification. By default, all classifications are selected.
To get started, click Create List. Choose the notification types to be sent, then click Add Recipient to assign
a new recipient to your list. Recipients may be added to more than one list. Click on a distribution list to view
its recipients. You can edit an existing recipient if needed.
FortiEDR comes pre-configured with an All recipients list, which contains all recipients added to all your
distribution lists. This list can’t be edited.
FortiEDR 4.2 Study Guide
138
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now you will learn about export settings. This is where you can configure all your notification types. You can
enter your SMTP settings, which you’ll need for any email notifications. Please be careful with these—if you
delete or accidentally alter them, all your email alerts will be disabled.
You can also open a ticket automatically with your event management system, for example Jira or
ServiceNow. First you’ll need to set up a receiving email feed in your event management tool. The Installation
and Administration Guide has instructions for how to do this in ServiceNow. When you’ve got that set up,
enter the email address for the feed here.
Lastly, you can configure your syslog parameters. Configure syslog to send data to a security information and
event management solution, like FortiNAC. Enter standard syslog parameters, then decide what types of
events to send. You can send security events, system events (like status changes, upgrades, or new
installations) or the audit trail, which lists user actions in the management console. You’ll learn more about
system events and the audit trail later in this lesson. Remember that all security event notifications are
enabled in playbooks. After you configured your email settings and lists, open ticket settings, or syslog
settings, go to the Playbooks sub-tab and choose which event classifications will trigger each type of
notification. By default, all classifications trigger all notification types, as long as you’ve configured them on the
Administration tab.
FortiEDR 4.2 Study Guide
139
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Next is the Tools pane. You’ll find a lot of useful features here. First, you can generate an audit trail. The audit
trail is a list of actions performed on the management console. If an administrator creates a user, moves a
collector, or views an event on the Forensics tab, that will be recorded in the audit trail.
Below that is Component Authentication, where you can gain access to the registration password. You
need the registration password to install, disable, or uninstall a collector. This prevents unauthorized collectors
from connecting to your aggregator and using your licenses, and also prevents users or malware from
uninstalling the collector. The password is set during the initial system installation. Click the Display button to
see or copy the password. Note that in multi-tenant environments, each organization has its own password.
Under Automatic Updates, you have the option to automatically update all the collectors in your system
when a new version is available. Some customers prefer to update collectors manually on the Licensing
pane. Others just want the latest collector—they don't want to administrate it. In that case, you can check this
box, and it’ll automatically push the latest upgrade to all your collectors.
You have the option to scan all the files in your network, either on a regular basis, or ad hoc. Please note that
this is an optional function. FortiEDR does not rely on file scans to protect your system.
Configure end-user notifications to control what information your end users receive about the FortiEDR
collector’s activities. Add a FortiEDR icon to the user’s system tray for Windows users or menu bar for Mac.
This icon is a quick way of finding out if the collector is installed and active, which is useful information for
troubleshooting. You can also enable pop-up notifications that tell the user when FortiEDR has blocked
something. You can customize the message to include information relevant to your organization.
Under IoT Device Discovery, enable ongoing scans to track the IoT devices that connect to your network.
You can also enable Inventory Auto Grouping to organize your devices.
Lastly, you have the Personal Data Handling section for GDPR compliance. You can search your entire
system by user, device, IP address, and MAC address, and delete any associated data.
FortiEDR 4.2 Study Guide
140
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
Now take a quick look at system events. System events are one of the notification types that you can send
through email or syslog. These are system hygiene events—events that affect the protection of user devices.
For example, you’ll see a system event when a new collector is registered, a collector’s state changes, a core
or aggregator goes up or down, or you reach your license capacity.
FortiEDR 4.2 Study Guide
141
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
IP sets allow you to define a set of specific IP addresses, like AWS IPs, database servers, domain controllers,
and so on. You can apply IP sets to an event exception—for example, you can allow a process to
communicate only with Google IPs or only with your credit card servers.
You can create as many IP sets as you need. Add IP addresses individually, by range, or by subnet. You can
also exclude specific IP addresses from an allowed range.
FortiEDR comes out of the box with an internal destinations IP set. You can’t edit the IP addresses in the list,
but you can add to it and put addresses in the excluded IPs list.
FortiEDR 4.2 Study Guide
142
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
On the Integrations pane, you can create connectors to integrate with other Fortinet products. You can
integrate with FortiGate to enable automatic blocking of malicious destinations involved in security events.
When your connector is configured, you’ll have the option to enable Block address on Firewall action in
playbooks.
Integrate with FortiSandbox to enable additional file analysis by FortiSandbox. You’ll need to enable the
Sandbox Analysis rule in your execution prevention policies to use this feature. Events triggered by this rule
will appear in the Event Viewer along with all the other security events.
In a multi-tenant environment, integrations are configured on a per-organization basis.
There are a number of requirements for integrating FortiEDR with FortiGate or FortiSandbox. First, make sure
your management server has connectivity with FCS. You’ll need an on-premises core with connectivity to your
FortiGate server or your sandbox. You also must have a valid management console user with API
permissions as well as a valid API user with access to FortiGate or FortiSandbox.
To fully integrate your systems, additional configuration steps are required. You’ll find detailed instructions in
the FortiEDR Installation and Administration Guide.
FortiEDR 4.2 Study Guide
143
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
The last panel on the Administration tab is available for the support admin user. Other users, even with
administrator permissions, will not see this panel. In this panel, you can customize your management console
with your own branding. Click Download Template Theme to get a zip file with all the images used on the
GUI, as well as a properties file and a CSS file. Replace the image files with your own logos, and update the
properties and CSS files to reflect your own branding.
You can click Restore Default Theme at any time to return to the original Fortinet look and feel.
FortiEDR 4.2 Study Guide
144
The User Interface In Depth, Part 2
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
145
The User Interface In Depth, Part 2
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 the functions of the FortiEDR
management console.
FortiEDR 4.2 Study Guide
146
Events and Alerting
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about security events and alerts.
FortiEDR 4.2 Study Guide
147
Events and Alerting
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in events and alerting, you will be able to understand and manage security
events.
FortiEDR 4.2 Study Guide
148
Events and Alerting
DO NOT REPRINT
© FORTINET
When you are reviewing security events, you want to have enough information to decide on a course of
action, but not so much information that it becomes overwhelming. FortiEDR aggregates security event data
so that you can start with a high-level alert and drill down to get more detail as needed. For example, let’s say
a piece of malware is triggered on three separate devices. Each time the process is triggered on a new
device, a separate event is created. If you aggregate events by process, all the events will be part of the same
alert: three events rolled up into one alert. If that malware tried to communicate across the network, it could
attempt to connect to many network destinations, and each attempted connection to a new destination would
result in a separate raw event. Many raw events are rolled up into a single event, and then, at the highest
level, those single events are rolled up into alerts.
FortiEDR 4.2 Study Guide
149
Events and Alerting
DO NOT REPRINT
© FORTINET
How does FortiEDR detect and handle security events? FortiEDR comes out of the box with four types of
security policies: execution prevention (or NGAV), exfiltration prevention, ransomware prevention, and device
control. These policies are each made up of a set of rules related to the behavior of a file or process. The
FortiEDR collector, which is installed on every device in your network, takes snapshots of activity on the
device. When an activity violates a rule, you receive an event. For example, you can see that the event in the
example shown on this slide violated the malicious file detected rule and the unmapped executable rule.
Malicious file detected means that FortiEDR recognized the file as malicious. When a file is flagged based on
machine learning or other analysis, FortiEDR generates an alert whenever it sees that file. Unmapped
executable means the executable is running in memory with no corresponding file. This is a common method
of hiding malicious code or behavior, so it also generates an event.
Rules are assigned actions. In most cases, the default action is block: if an event violates the rule, FortiEDR
will automatically block it. For less serious rules—behaviors that are suspicious but could be legitimate—the
default action is log. If needed, you can change these actions on the Security Settings tab. When an event
violates more than one rule, the more serious violation determines the action. In other words, if one rule is set
to block and one is set to log, and the event violates both rules, the event will be blocked. You can see the
action taken at the end of the event row.
FortiEDR 4.2 Study Guide
150
Events and Alerting
DO NOT REPRINT
© FORTINET
Classifications are a guide to help you prioritize events. A classification of malicious indicates that you should
investigate and remediate the event as quickly as possible, but likely safe events are less urgent. You will
learn about each classification on the next slide.
How are classifications assigned? When an event takes place, the core automatically assigns it a
classification. In the example shown on this slide, in the History section, you can see that the event was first
classified as suspicious. This is part of the immediate response to the event. You’ll notice the time stamp is 10
June 2020 at 3:47 and 55 seconds. After the event, the Fortinet Cloud Service (FCS) reviews it in more detail
and decides whether the original classification should be changed. If you look at the example again, you’ll see
that FCS reclassified the event as malicious. FCS took slightly longer to respond to the event—you’ll notice
the time stamp is 3:48 and 10 seconds, which is about 15 seconds after the core logged the event. So the
core responds instantly to the event, and then FCS fine-tunes the classification if needed.
The classification determines the playbook actions that should be taken, if any. In the example shown here,
the affected device shown in the History section would have been moved to the High Security Collector
Group; however, the playbook was in simulation mode.
As a management console user, you can also manually reclassify an event based on your analysis. For
example, if you investigated a suspicious event and verified that it was caused by malware, you can mark it as
malicious so if it comes up again, you’ll know it’s bad, and you won’t have to investigate it again. You will learn
more about reclassifying events a little later in this lesson.
FortiEDR 4.2 Study Guide
151
Events and Alerting
DO NOT REPRINT
© FORTINET
This slide shows all the event classifications. First on the list are malicious events. These are the most serious
events—they are bad, they have no potential use, and you should remediate the device.
Second are suspicious events. Suspicious events are most likely malware, but it hasn’t been verified. You
should review these events to make sure they’re not legitimate, then remediate the device as needed.
The third category is inconclusive. This classification indicates that there is conflicting information, or not
enough information to determine if the event is malware. You should review these events. If you determine
that the events are malicious, remediate the device. If you determine that they are safe, you can create an
exception so it won’t come up again.
Next are potentially unwanted programs, or PUPs. These are not necessarily malware, but they are
processes that you should not run. Often these programs are bundled with legitimate software—browser
plugins, for example—or they may be high-risk applications like torrents. You should review these events and
decide whether to remove the program or create an exception to allow it.
The last two categories are the least serious. A likely safe classification means that the event is probably
legitimate. It is not possible to verify it 100%, but you can assume that there is very little risk. Review these
events to make sure they look OK, then create an exception. Software that is classified as confirmed safe is
definitely legitimate. Normally, you will not see safe events in your events list. If FortiEDR determines that an
event is confirmed safe, it automatically creates an exception and marks the event as expired. If the process
runs again, it will be allowed.
FortiEDR 4.2 Study Guide
152
Events and Alerting
DO NOT REPRINT
© FORTINET
Now look at event aggregation in a little more detail. Events are aggregated into alerts by device or process.
Each method of aggregation is useful for different types of investigation. For example, you may want to
choose the process view if you want to see the impact of a single malware process across your network. In
the example shown on this slide, the events are aggregated by process. You can see that the network has two
events that involve Locky.exe. If you’re troubleshooting a specific device, you might want to choose the device
view so you can see all the events involving that device. If you want to see the events in an alert, just click on
the alert in the list to expand it.
The alert classification comes from the most serious event classification within that alert. So, if an alert
contains one event classified as malicious and three events classified as inconclusive, the alert would be
classified as malicious. This classification system is intended to draw your attention to the most urgent events.
An alert also gets its received date from the events—the most recent date that an event was first received is
the alert received date—in this example, 23rd of October 2018.
Raw events are aggregated into events. Each event is assigned a unique event ID. In this example, the first
Locky event listed is event 3026810. If you click the row, you’ll see more detail: the user, the path, and
whether the certificate was signed. At the end of the row, you’ll also see the number of Raw data items—in
this example, 2. An event may be associated with just one raw event, or hundreds. To view raw event details,
click the triangle on the left end of the row.
FortiEDR 4.2 Study Guide
153
Events and Alerting
DO NOT REPRINT
© FORTINET
The example on this slide shows the raw event data—you can see each piece of raw data collected by
FortiEDR that led to the event. In this example, you can see event 173292, and there are two raw events
within that event, each with its own raw ID. The file was read four times between October 16 and November 4
and attempted to execute seven times during the same period. File read attempts and file execution attempts
trigger two different rules, so there are two raw events—one for all the times the file was read and one for all
the times it tried to launch.
You’ll notice that each raw event is assigned a raw ID. These are separate from the event ID.
Wherever applicable, you can view the external destination of each raw event on the Advanced Data pane.
FortiEDR 4.2 Study Guide
154
Events and Alerting
DO NOT REPRINT
© FORTINET
Now take a look at playbooks, or automated incident response. A playbook is a set of actions that FortiEDR
can perform automatically for you when an event occurs. You can assign actions based on the event
classification—for example, you might want to automatically terminate the process for a malicious event.
However, if the event is classified as inconclusive, you may prefer to investigate it before you terminate the
process.
Playbook actions include all notifications—email, syslog, and open ticket. Please note that you won’t be able
to send notifications until you configure them on the Administration tab.
The next set of actions are related to investigation. These actions help contain the infection while you
investigate. They include Isolate device, which puts the device into isolation mode. In isolation mode,
communication is blocked from all applications unless specifically marked Allow. You also have the option to
select Move device to High Security group, which puts the collector into the built-in High Security Collector
Group. This group should be kept in protection mode at all times. Isolation mode and the High Security
Collector Group are intended to offer additional protection to devices when malware is detected. They are
intended to be temporary measures, and are not required for FortiEDR to protect your system.
You can also enable automatic remediation steps. These include terminating the process that triggered the
event, deleting malicious files, and cleaning persistence data. These actions can’t be undone, so you may
want to apply them only to events involving known malware. Also keep in mind that FortiEDR will delete only
those files that are confirmed to be malicious. If FortiEDR is not highly confident that a file is bad, FortiEDR
won’t delete it. Remediation actions also include Block address in firewall, which allows you to automatically
block any malicious destination IPs in your firewall. You’ll need to configure your firewall on the
Administration tab before you can enable this option.
Playbook actions are shown on the Classification Details panel on the Event Viewer. Notifications aren’t
shown in this tab, but you will see all other actions.
FortiEDR 4.2 Study Guide
155
Events and Alerting
DO NOT REPRINT
© FORTINET
Operational modes—protection mode and simulation mode—apply to each policy, including security policies
and playbooks, but they work a little differently in playbooks. You will start by reviewing security policy modes.
Imagine that a process has violated a policy rule with an assigned action of block. If the rule belongs to a
policy in protection mode, then FortiEDR will block the event. This is what should happen normally—it’s a key
way FortiEDR protects your system. If the rule belongs to a policy in simulation mode, FortiEDR will log the
event as simulation block, but allow it to continue.
Now imagine that the same event triggers playbook actions—maybe it’s classified as malicious, and you’ve
configured your playbook to send a syslog notification and terminate the process for malicious events. If the
playbook is in protection mode, all selected actions are carried out—the notification is sent and the process is
terminated. If the playbook is in simulation mode, the notification will be sent, but the process will not be
terminated. On the Classification Details panel, you’ll see the process termination marked as Simulation so
you can see what would have happened if the playbook had been in protection mode.
FortiEDR 4.2 Study Guide
156
Events and Alerting
DO NOT REPRINT
© FORTINET
How do you find an event? Often, you’ll want to view your highest priority items first. One way to do this is to
filter by status. By default, only unhandled events are shown, so you can focus on events that haven’t been
dealt with. You can also use the filter to view unread events, archived events, or device control events—
events related to devices that have been blocked by your device control policy, if enabled.
You can also use sorting to help prioritize events. You can sort by any column heading in the events list.
Sorting by date is a great way to see what’s actively affecting your system. You’ll notice two dates for each
event—one is received, which is the first occurrence of that event, and the second is last updated, which is
the most recent occurrence of an event. In some cases, like the example you see on this slide, the two dates
are the same, but sometimes the event happened several different times, so these dates might be days or
weeks apart.
Device and process views are also designed to help you work more efficiently. In device view, you can see all
the events that happened on a particular device. This can be useful if you are investigating a problem reported
by a particular user. Select the process view and you can find all the devices that are affected by a particular
process. This is a useful view for finding all the instances of a particular process—how many times has this
malware affected my environment? Process view is also generally the most efficient choice for event tuning.
You’ll learn more about event tuning in a later course.
If you’re looking for a specific event, you can use the search function. To do a simple search, enter your
search term in the search field at the top of the list. If you already know the event ID, you can enter it here and
you’ll find it right away. If you want to search by more than one criteria, you can click the little gray arrow
towards the right side of the search field to open the advanced search window. There, you can search by a
combination of any of the criteria in the window, which you can see in this example on the lower right. For
example, you might search for blocking events affecting a particular collector, or events on a certain day
involving a specific process and classified as malicious.
FortiEDR 4.2 Study Guide
157
Events and Alerting
DO NOT REPRINT
© FORTINET
You’ll remember from earlier lessons that the Forensics module gives you lots of detailed information about
an event. If you’re investigating an event to see if it’s malicious, you’ll want load it here. Now, you’ll review
how to get events into the Forensics tab. First, in the Event Viewer, select the checkbox for each event that
you want to see and then click the Forensics button at the top of the list. Note that if you click the Forensics
tab, the events won’t load, you will see only the empty Forensics tab. When you click the Forensics button,
the selected events will be loaded into the forensics engine and you can look at them in detail.
To add more events to the Forensics module, you can return to the Event Viewer and repeat the same
process. Click the checkbox, then the Forensics button. If you see a fingerprint next to an event, it’s already
been loaded in Forensics.
The Forensics tab can become very crowded after a busy day of tuning. Loading too many events at once
may slow down your system, so Fortinet recommends periodically clearing events from the Forensics tab.
You can click the Clear All button in the upper-right corner to remove all events from the tab, or you can close
events individually.
FortiEDR 4.2 Study Guide
158
Events and Alerting
DO NOT REPRINT
© FORTINET
Say you’ve investigated an event and you’re sure it’s safe. Your next step is to create exceptions. An
exception is a way of indicating that even though a process breaks a rule, you have determined that it is safe.
So, if that process breaks the same rule again, FortiEDR won’t block it.
Exceptions apply to a specific rule violated by a specific process. Sometimes, a single process violates more
than one rule. When that happens, you may need to create more than one exception to allow the process to
run. If both rule violations were in the same event, you’ll see each rule listed in the Exception window. In the
example shown on this slide, the process SWService.exe violated the unmapped executable and
unconfirmed executable rules in the same event. You can use different criteria for each rule. For example, in
the example on this slide, the unmapped executable exception has been applied to the memory unique
identifier, but the unconfirmed executable exception applies to any path.
The best practice is to minimize the paths and destinations covered by the exception. You can use IP Sets
and add wildcards to file paths to reduce the need to apply the exception to all destinations or any path. You
will learn about exception settings in detail in a later lesson.
Fortinet also suggests applying exceptions to all groups unless you have a specific reason not to. Exceptions
are applied to collector groups rather than individual collectors, so if a collector moves to another group, it will
lose its exceptions unless the same exceptions are applied to both the new and old group. Applying
exceptions eliminates this problem and reduces helpdesk requests.
FortiEDR 4.2 Study Guide
159
Events and Alerting
DO NOT REPRINT
© FORTINET
Now take a quick look at how to apply and manage exceptions. When you click on an event in the events list
to view its details, you can see the Exception button on the left. When you click the Exception button, you
can see whether the selected event is already covered by an existing exception. When you see the icon
without a pencil, with the green diamond at the upper left, there’s no existing exception. Click this button to
create a new exception. If you see the icon with the green pencil at the upper right, there is at least one
existing exception. Click this button to view the exception and edit it if needed. For example, you might want to
know when the exception was created so you can determine whether the event you’re looking at happened
before or after the exception was created. If it happened after, you may need to widen the parameters. You’ll
learn more about that on the next slide.
You can click the Exception Manager button if you want to see all the exceptions that are in place in your
environment. You can search the exceptions for a particular process, event ID, and so on, or you can use the
advanced search to look for multiple criteria at once. You can edit exceptions directly from the exception
manager—just click the exception icon on the right side of the exception row. It’s the same icon you saw in the
events list for events with an existing exception. You can also delete exceptions—just click the trash icon at
the end of the row. You also have the option to export a list of exceptions to a PDF or Excel file.
FortiEDR 4.2 Study Guide
160
Events and Alerting
DO NOT REPRINT
© FORTINET
Now take a look at the relationship between exceptions and order of operations. As you remember, security
policies are made up of rules, and exceptions apply to specific rule violations. FortiEDR enforces its policies in
a specific order. First, when the file is read or attempts to execute, it’s checked against the execution
prevention, or NGAV, policy. This is where most infections are stopped. If the process is allowed to continue,
the post-infection prevention policies kick in—exfiltration prevention checks all attempted network
connections, and ransomware prevention checks all attempts to alter files.
Why does this matter? In protection mode, the process is often stopped by the first blocking rule. For
example, if it’s stopped by the suspicious file detected rule in execution prevention, it won’t be checked by the
exfiltration or ransomware prevention policies. That means if you create an exception allowing the process to
run even if it violates the suspicious file detected rule, you might not see any other violated rules. The process
never launched, so it was never checked by the other policies. When you put your exception in place, the
process may still encounter further blocking events if it violates other rules—for example, when it tries to
connect to the internet. In this case, you’ll need to create additional exceptions for the new rule violations. In
the example shown on this slide, you can see two exceptions, both applying to the same process. The first
was created on July 29 and applies to the unconfirmed executable rule. The second exception was created
two days later and applies to the hidden process and unconfirmed executable rules. Does this mean the first
exception didn’t work? If you check the events the exceptions were created from, you can see that the rule
violated on July 29 was in the execution prevention policy, whereas both rules violated on July 31 were in the
exfiltration prevention policy. So the first exception allowed the file to execute, but it still required a second
exception after the exfiltration prevention policy checked it.
FortiEDR 4.2 Study Guide
161
Events and Alerting
DO NOT REPRINT
© FORTINET
There are a couple of different ways to mark an event that you have dealt with. First, you can mark the event
as Handled. When you mark an event as Handled, other management console users know you have already
investigated and dealt with the event, either by remediating the infection or creating an exception for a safe
process.
To handle an event, select the checkbox associated with the event. You can select the checkbox for an
individual event, or for all the events in an alert. Then click the Handle Event button. The Event Handling
pop-up window will open. You can use the settings in this window to change the event classification. For
example, you can change a classification of inconclusive to a classification of safe or malicious, depending on
your findings. The best practice is to include a comment explaining how you handled the event. Then click
Save as Handled.
Unhandled items are shown with a dark gray flag, and handled items are shown with a light gray flag. If you
want to see handled events, select All. The default view is Unhandled, which shows only events that haven’t
yet been dealt with; essentially, your to-do list. If an event recurs, it will be automatically marked as
Unhandled so you will know further investigation is needed.
FortiEDR 4.2 Study Guide
162
Events and Alerting
DO NOT REPRINT
© FORTINET
You can also archive an event. Archived events are not in the events list, even when the filter is set to All. To
archive an event, select its checkbox and click the Archive button at the top of the list. You can also select the
Archive When Handled checkbox in the Event Handling window to archive and mark as handled in one
step.
You can view all the archived events by changing the filter drop-down list on the left to Archived. You can
also search for archived events in the advanced search window by selecting Include Archived Events. If an
archived event recurs, a new event will be created and will appear in your main event list.
FortiEDR 4.2 Study Guide
163
Events and Alerting
DO NOT REPRINT
© FORTINET
Now you will examine some example scenarios. First, you will explore events that affected a specific group.
The scenario is this: employees in your Philadelphia office have been experiencing problems, so you want to
know if any blocking events have affected that office in the last week. The best way to do this is to use the
advanced search feature to search for a specific subset of events based on multiple criteria: in this case,
collector group and time frame. In the Event Viewer, open the advanced search dialog by clicking on the gray
arrow inside the search bar. You know the problem has occurred over the last week, so you want to see
events that have occurred during that period. To do this, beside Last Seen, in the From field, select 17-Aug2020. In this setting, last seen means the most recent occurrence of the event. Next, in the Collector Group
drop-down list, select Philadelphia office. It’s a good idea to select Include Archived Events to make sure
that you get a complete list.
Review the list for events that could have caused problems for end users in the Philadelphia office. The most
likely cause is either a safe process that was blocked, or a malicious process that was allowed, either
because the device was in simulation mode or an unsafe exception was applied. Remember that even if an
event is triggered by a safe process, it may still be malicious. A common example is an event triggered by a
malicious script in a Microsoft Word file. Make sure you investigate events carefully before applying an
exception, and keep your exceptions as narrow as possible.
FortiEDR 4.2 Study Guide
164
Events and Alerting
DO NOT REPRINT
© FORTINET
Now you will review a scenario in which you are investigating an inconclusive event that has communicated
with multiple destinations. In this scenario, you want to know what those destinations were. You can get
detailed information about IP destinations for the highlighted event in the Advanced Data section, using Geo
Location. Note that geo location service is not available for all events. Geo location is available only if the
process attempted to communicate with an external IP address. When you click on an event in the list, look in
the Advanced Data section to see if geo location is available. In the example shown on this slide, it is
available. When you click Geo Location, you will see a map with a pin marking each country the process
attempted to communicate with. Click the arrows to see each IP address and autonomous system information.
In the example, you can see that there are two destinations corresponding with two raw data items. The first
destination is associated with Netdirekt A.S. in Turkey, so you could do an internet search on that company
and the IP address to determine whether it is safe or not. Each destination represents a different raw event, so
you can also view the map from the raw data items panel. Click on each raw event to see which one was
associated with each destination.
You can find other events that have attempted to communicate with the same location by performing an
advanced search. Just copy the IP address and enter it in the Destination field.
FortiEDR 4.2 Study Guide
165
Events and Alerting
DO NOT REPRINT
© FORTINET
In the scenario shown on this slide, you receive an alert on a process you know is safe, and you want to know
whether that alert is covered by an existing exception. Remember, when a process violates several rules, it
may be blocked, even if an exception is in place. Expand the alert and the event you want to investigate, and
in the details row, check the Exception button. If the event looks like the top example, there’s no exception.
Investigate the event to be sure that it is safe. If needed, click the Exception button to create an exception. If
you see a pencil icon, you can click it to see the existing exceptions and determine whether you need to
create a broader exception. In the Exception window, check the date the exception was last updated. Now,
return to the events list and check the Last Updated column. If all the events occurred before the exception
was last updated, you don’t need to edit the exception. If the event has been updated since the exception was
created, you know the exception didn’t cover all scenarios. For example, the event might have tried to
communicate with a destination that wasn’t covered in the exception. Investigate the event and broaden the
exception as needed.
FortiEDR 4.2 Study Guide
166
Events and Alerting
DO NOT REPRINT
© FORTINET
You can automatically send FortiEDR event data to an event management system, to a logging or
logging/SIEM solution through syslog, or to a set of console users through email. To do this, you must
configure your notifications on the Administration tab. On the Administration tab, under Export Settings,
you can configure three types of exports. The first is your SMTP parameters. SMTP parameters allow
FortiEDR to send automated email alerts. If you’re in a multi-tenant environment, SMTP parameters are
available only in the hoster view. After you configure your SMTP settings, you can decide which console users
should receive email alerts on the Distribution Lists pane. Make sure you enable Security Events for your
distribution list, if you want to send security event alerts by email.
You can also open tickets in an event management tool, like Jira or ServiceNow. This requires email, so you
need to set up a receiving email feed in your event management tool. The FortiEDR Installation and
Administration Guide includes instructions for how to do this in ServiceNow.
Lastly, you can configure syslog notifications. Click Create New Syslog and enter the standard parameters.
Make sure you enable Security Events for your syslog if you want to receive security alerts.
Playbooks determine what event classifications trigger each type of alert. After you configure a notification
type in the Administration tab, go to Playbooks under the Security Settings tab to configure which
classifications will trigger that notification. Remember, notifications will be sent even when the playbook is in
simulation mode.
FortiEDR 4.2 Study Guide
167
Events and Alerting
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
168
Events and Alerting
DO NOT REPRINT
© FORTINET
This slide shows the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned more about FortiEDR security events and
alerts.
FortiEDR 4.2 Study Guide
169
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
In this lesson, we will discuss how to troubleshoot help desk calls related to FortiEDR.
FortiEDR 4.2 Study Guide
170
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives on this slide.
By demonstrating competence in help desk level 1 triage, you will be able to perform basic troubleshooting for
FortiEDR-related help desk calls.
FortiEDR 4.2 Study Guide
171
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
This slide shows a brief overview of the FortiEDR troubleshooting approach. Imagine that a user has called
because they’re not able to print a PDF document. The user knows that the FortiEDR collector was being
installed today, and thought that it might be causing the problem.
The first thing you should do is determine if the collector is installed. Because FortiEDR is deployed in waves,
FortiEDR may not even be installed for the user yet. If the collector is not installed, then the user’s issue is
definitely not related to FortiEDR.
If the collector is installed, you need to determine whether the collector’s group is assigned to policies in
protection mode. Remember, policies in simulation mode are not actively enforced. If all the associated
policies are in simulation mode, FortiEDR is not causing the problem. During deployment, all collectors should
start in simulation mode to reduce support calls and productivity blockers.
If some or all of the policies are in protection mode, the next step is moving the collector into a group whose
policies are in simulation mode. If the problem persists, you can skip ahead to stopping the collector.
If the problem goes away in simulation mode, then it’s likely that the process was blocked by a FortiEDR
policy. First, check for blocking security events. Since these are cases of malware or suspected malware, be
sure to to examine the events carefully before deciding on a course of action. You may need to escalate the
event. If you don’t see any security events that have been blocked, check the assigned communication control
policy. Remember that connections may be blocked from otherwise safe application because of a known
vulnerability in the application version. Check carefully for any explanation for the blocking policy, and
escalate the issue, if necessary. You may also find that the collector is in isolation mode, which contains
active infections by severely restricting network connections. Escalate these cases as well.
If you can’t find any blocking events or policies, try disabling the collector. If this solves the user’s issue,
contact Fortinet support. On very rare occasions, you may need to temporarily uninstall the collector. If
uninstalling the collector solves the problem, contact Fortinet support.
FortiEDR 4.2 Study Guide
172
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
Now you will go over each of these troubleshooting steps in a little more detail. When you get a call about a
potential FortiEDR issue, the first thing to find out is whether the FortiEDR collector is installed on the device.
The first and easiest way to find out if the collector is installed is to look for the notification icon. You can find it
in the System Tray on a PC or the Menu Bar on a Mac. The notification icon also gives you some information
about the state of the collector. Any shield indicates that the collector is installed, but what you generally want
to see is a green shield. A green shield means that the device is being protected. A gray shield indicates that
the device is not being protected, possibly because the device has been disabled. If you see a gray shield
outlined in yellow, the collector is degraded. That means it’s not performing to full capacity. Lastly, a green
shield outlined in red means the collector is in isolation mode.
The presence of any color of shield icon indicates that the collector is installed. However, if you do not see the
shield icon, this does not necessarily mean that the collector is not installed. In some cases, it might be hidden
because there are too many other processes competing for space, or an administrator may have chosen not
to show collector icons in the deployment.
If you don’t see an icon, there are two more methods you can use to determine if the collector is installed.
First, you can check the local process lists on the user’s device. In the Task Manager on a PC or the Activity
Monitor on a Mac, search for FortiEDR collector. If it’s running, you will see the process in the list.
Lastly, if you have access to the management console, you can go to the Collectors sub-tab on the
Inventory tab and search for the collector name (the device name). Doing this will also provide additional
information about the collector version that’s installed and the current state of the collector.
FortiEDR 4.2 Study Guide
173
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
All the collectors that have been installed in your organization are listed on the Collectors sub-tab on the
Inventory tab. You can find a lot of useful information here that will help you diagnose possible FortiEDRrelated issues.
First, remember that collectors are listed under their assigned collector groups. As you may recall from earlier
lessons, policies are applied at the collector group level. This means you can apply strict settings to one
group, for example, the High Security Collector Group or the Finance department, and less restrictive settings
to lower-risk users. Keep this in mind when moving a collector to a different group. Sometimes collectors are
intentionally moved to stricter groups, for example, if they were infected. In other cases, programs that were
allowed in one group may be blocked in another, causing unnecessary productivity inhibitors and support
calls. To determine which policies apply to a specific user, you’ll need to know which group their collector
belongs to. If you have a lot of collector groups, you can always search for the collector by name in the search
bar.
Another useful piece of information is the collector’s state. You may remember that when you first load the
collectors list, only degraded collectors are shown. Degraded collectors are not performing at full capacity, so
they may not be adequately protected. This may be caused by compatibility issues or lack of resources on the
device, for example. If you hover your cursor over the collector state, you’ll see a brief description of the
problem, which can help you determine the best course of action. It’s important to address these issues to
ensure that the collector and your network are fully protected.
FortiEDR 4.2 Study Guide
174
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
Now you will learn about determining which policies are assigned to a Collector group. First, check the
security policies, located under the Security Settings tab. When you click a policy, the Assigned Collector
Groups pane on the right shows you a list of all the collector groups assigned to that policy. Each collector
group should be assigned to one execution prevention, one exfiltration prevention, and one ransomware
prevention policy. Search for a collector group name to view only the policies assigned to that group.
Next, check the communication control policies assigned to the collector group. Search for the collector group
to see only the communication control policy assigned to that group. If any applications have been set to Deny
for that policy, they won’t be able to communicate over the network, which may cause user issues. Remember
that communication control policies cannot block an application from running; they only affect network
connections. If a user calls because they can’t launch a particular program, the problem is probably not
related to communication control.
The last type of policy to check is the playbooks. Playbooks don’t directly block processes or connections, but
they can affect the end user in the event of a malware infection. They may put the affected collector into
isolation mode, which would prevent communication from nearly all applications. Playbooks can also move a
collector to the High Security Collector Group. In some cases, a process that had an exception applied in the
user’s usual collector group, may be blocked by a playbook. Playbooks can also delete a malicious file from
the user’s device, block a specific IP address, and more.
The first thing you should to check is whether the policy is in protection mode. Policies in protection mode are
marked with a green slider like you see in the security policies shown on this slide at the upper right. A policy
in simulation mode is marked with a gray slider and will not be actively enforced. So, any simulation mode
policies assigned to a user’s collector group are not the cause of the user’s problem. During deployment, you
may see a collector group assigned only to policies in simulation mode. In this case, you can rule out blocking
events as the cause of the problem. If one or more of the policies are in protection mode, you’ll need to move
the collector that you are troubleshooting to a simulation group.
FortiEDR 4.2 Study Guide
175
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
If the collector you’re troubleshooting is in a group whose policies are in protection mode, the next step is to
move it to a simulation group. It’s a best practice to move an individual collector to a new group rather than
change the policy assignments for the entire group. If you move one collector, the rest of the group is not
disrupted. Fortinet recommends maintaining a simulation group, with all its assigned policies in simulation
mode, for this purpose. Remember, in simulation mode, FortiEDR won’t block processes or connections, so
make sure you move the collector back to its original group when you’re finished troubleshooting.
Moving a collector to a new group is a simple procedure. On the management console, go to the Collectors
sub-tab on the Inventory tab and find the collector you want to move. Select the checkbox next to that
collector, then click Move to Group. This will open the Collector Groups dialog. In the dialog, click the new
collector group and click Move to Group to save your changes and close the dialog.
FortiEDR 4.2 Study Guide
176
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
If moving the collector to simulation mode resolved the user’s problem, the next step is to find blocking events
for the collector. Start with security events. All security events, whether they are logged or blocked, in
simulation or protection mode, are recorded on the Event Viewer tab of the management console. For
troubleshooting, you’ll be focused on events that were blocked by FortiEDR. In the Event Viewer, click
Device to view events grouped by device. This makes it easier to find any events affecting a particular user.
You can enter the device name in the search bar to narrow the list to just one collector. If there are events
involving that collector, look for a red icon at the end of the row. In the example shown on this slide, you can
see that four processes were blocked by FortiEDR. If you think this caused a problem for the user, escalate
the event for further analysis. Even if it involves a known and safe process, it’s important to investigate the
event thoroughly to make sure it is what it claims to be and hasn’t been hijacked by a malicious process. For
example, an event involving winword.exe could be unsafe if the user has unknowingly allowed a malicious
macro to execute.
If you see the same icon in gray, the policy was in simulation mode at the time of the event, so the event was
not blocked. If the user tried the process before and after you moved their collector into the simulation group,
you may see a blocked and simulation block event for the same process.
If you don’t see any blocking events for a user, they may still be affected by a block in communication control.
FortiEDR 4.2 Study Guide
177
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
If you don’t find any blocking events in the Event Viewer, the next step is to look for communication control
policies that may be blocking a particular application. If a user calls support and says their FTP application
can’t connect to the network, for example, you’ll want to know if a communication control policy might be
blocking that application. There are several ways to do that. First, find the application in the applications list.
You can type the application name in the search field to find it quickly. Click on the application row to highlight
it. The Application Details pane to the right of the list shows the selected action for the highlighted
application in each of the communication control policies. In the example shown on this slide, you can see the
application details for Google Update. It is set to Deny in the Default Communication Control Policy, the
Accounting policy, and the Servers Policy, which blocks all applications by default. Remember that an
application may be allowed to communicate in some versions, but not in others.
Second, you can use the advanced applications search to view a list of applications set to Deny in a given
policy. You can do an advanced search by clicking the gray arrow on the right side of the search bar. In the
Search Applications window, set the Action to Deny. Then choose one or more policies from the Policy
drop-down list. If you don’t know the policy for the user’s collector group, you can leave that field blank. If
you’re searching for a particular user, you can enter their collector name (the device name) in the Collector
field. You can also type values in the Application or Version fields if you are investigating a problem with a
specific application, In this example, you would get a list of any versions of Dropbox that are set to Deny in
the Default Communication Control Policy.
You can also use the Policies sub-tab to find blocked applications and versions. Find the policy assigned to
the collector group, and check the Affected Apps column in the policy row. Click Total x denied apps to see
a list of applications that are set to Deny in the policy. So, in the example shown on the slide, you would see a
list of the 18 applications that are set to Deny by the Default Communication Control Policy.
FortiEDR 4.2 Study Guide
178
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
Isolation mode uses a special built-in communication control policy to block external connections. Unlike most
communication control policies, it isn’t assigned to a collector group. Instead, isolation mode is a state
intended to temporarily protect and quarantine infected collectors while they are being remediated. Collectors
can be put into isolation mode automatically by a playbook, as you learned earlier, or manually by a
management console user. While a collector is in isolation mode, it is assigned to the isolation policy in
communication control, which blocks communication from all applications by default. There are no exceptions
built in to this policy. Fortinet recommends allowing communication only from applications that are needed for
remote investigation and remediation. In the Isolation Policy shown on this slide, you can see that only five
applications are allowed to communicate. You can click the number of allowed applications to see the
applications list filtered to only those five applications.
Because isolation mode is so restrictive, it should only be used temporarily. When the device is fully
remediated and no new infections have occurred in the last seven days, it is safe to remove it from isolation
mode.
If a user calls the help desk reporting that they are unable to connect to the internet after a recent malware
attack, their collector could be in isolation mode. There are two ways to verify if isolation mode is causing the
user’s connectivity issues. First, ask the user to check the collector status icon in their system tray or menu
bar. If the shield icon is outlined in red, the device is in isolation mode. However, you may not always be able
to see the collector status icon. You can also check the device status by finding it on the management console
under Inventory > Collectors. A red icon to the left of the device name, as shown on this slide, indicates that
the device is in isolation mode.
FortiEDR 4.2 Study Guide
179
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
Another way to find blocking events is in the local log files. Every machine that runs a FortiEDR collector
records the collector activity in the local log file. This includes processes blocked by FortiEDR security policies
and connections blocked by communication control policies.
To find logged events, search for the FortiEDR collector in the event log on the collector device. On the
Windows operating system, open the local Event Viewer application. In the navigation bar on the left, open the
Windows Logs folder and click Application. Look for any events whose Source is FortiEDR Collector. On
a Mac, open the OS console log and look for fortiEDRCollector.
FortiEDR 4.2 Study Guide
180
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
If you haven’t found any blocking events that may be causing the user’s problem, you can temporarily disable
the collector. The easiest way to do this is in the management console. Click Inventory > Collectors. Select
the checkbox next to the collector name and click the Enable/Disable menu button at the top of the list and
choose Disable.
If you can’t disable the collector remotely, you can stop the collector process on the user’s device. To do this,
you will need the registration password that is used to verify FortiEDR installations in your organization. If
disabling the collector resolved the problem, you should contact Fortinet support.
As a last resort, you can uninstall the collector to see if that resolves the user’s problem. This should only be
needed in rare cases. If the collector is currently connected, you can remotely uninstall it from the
management console. Select the device checkbox and click Uninstall. If the device is disconnected, this
button will be grayed out. In this case, you can manually uninstall the application from the user device. You
will need the registration password to manually uninstall, and to reinstall after troubleshooting. Again, if
uninstalling the collector solves the problem, contact Fortinet support.
FortiEDR 4.2 Study Guide
181
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
182
Help Desk Level 1 Triage
DO NOT REPRINT
© FORTINET
This slide shows all the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned help desk level 1 triage skills in order to
perform basic troubleshooting for FortiEDR-related help desk calls.
FortiEDR 4.2 Study Guide
183
Communication Control
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use communication control.
FortiEDR 4.2 Study Guide
184
Communication Control
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives on this slide.
By demonstrating competence in communication control, you will be able to configure and manage policies
and rules.
FortiEDR 4.2 Study Guide
185
Communication Control
DO NOT REPRINT
© FORTINET
First of all, what is communication control? Some applications are not malicious, but are inherently risky to
use: for example, any torrent applications, like BitTorrent. These applications don’t trigger an event because
they're not malware, but you may wish to proactively prevent them from sending information over the network.
Communication control monitors all applications that communicate over the network. The applications that
communicate over the internet pose the most security risk, and monitoring only those applications narrows the
problem set significantly, so that you can focus on potential vulnerabilities.
Communication control gives you the ability to choose which applications to block from communicating.
They're not actually removed from the computer, but communication is blocked. Communication control
policies are assigned at the group level, just like security policies, so an application can be allowed for one
group, but blocked for another. You can also block a specific version of an application if it’s known to have
security vulnerabilities, while allowing later versions that fix the issue.
FortiEDR 4.2 Study Guide
186
Communication Control
DO NOT REPRINT
© FORTINET
Why use communication control? The first key advantage is avoiding productivity inhibitors. Blocked
applications can still execute, they just can't communicate. Second is frictionless control, which reduces the
number of user requests to approve applications. Third is manageability. Security or IT needs to handle only
the applications that communicate externally. Fourth, FortiEDR offers reputation scoring. Each version of
every application is assigned a score, from one (known bad) to five (known good). These scores allow you to
easily identify potentially dangerous applications. Fifth, FortiEDR uses up-to-the-minute CVE data to assign a
vulnerability score to each application version. That means you can pinpoint exposed areas. Lastly, you can
mitigate risk by automatically blocking undesirable applications from communicating. You can set rules to
block any version of any application if it meets specified criteria. For example, you might block anything with a
reputation score of one, any version with a high or critical vulnerability score, or any application from a
specified vendor.
FortiEDR 4.2 Study Guide
187
Communication Control
DO NOT REPRINT
© FORTINET
FortiEDR can proactively block any application versions based on the criteria you select. This is a great
feature because it allows you to block future versions that don’t exist yet. After you put the rule in place, any
application that fits your criteria—for example, anything with a reputation score of two or less, or anything with
a vulnerability rating of critical—will be blocked from communicating. You can also proactively block specific
vendors and all their current and future products and versions.
Setting risk mitigation rules means your attack surface is much smaller. Any version of any application can be
blocked instantly and automatically. You don’t have to spend a lot of time in the console evaluating each
version and blocking the ones you don’t trust. FortiEDR will instantly block serious threats as they arise, and
you can review other applications on your own time, as needed. For example, say a critical vulnerability is
discovered in an old version of Java. If you’ve set a rule blocking anything with a critical vulnerability, that
version will be immediately blocked from communicating, preventing malicious actors from exploiting the
vulnerability to access your system. Other versions of Java will be unaffected.
FortiEDR 4.2 Study Guide
188
Communication Control
DO NOT REPRINT
© FORTINET
How does communication control work? It starts at the FortiEDR collector. The collector is installed at the
kernel level, so it can see everything that happens on the device. One of the things that the collector is
watching is which applications are communicating on the user's end device. It sends this data to the core, for
evaluation. The core sends the file hash to the reputation service, which sends back a reputation score. The
core also consults the CVE database and receives a list of CVEs for each application version. This list is
constantly updated, so you are informed about new vulnerabilities as soon as they are discovered. All the
applications and versions that have been detected are displayed in the management console, along with their
reputation and vulnerability scores, so you can easily spot potentially troublesome applications. Each
application and version is allowed to communicate or denied communication based on manual settings or
configured rules. The core sends this information back to the collector, which regulates connections from that
device based on the verdict it received from the core.
FortiEDR 4.2 Study Guide
189
Communication Control
DO NOT REPRINT
© FORTINET
How do communication control policies work with security policies? The first thing to know is the order of
operations. All the traffic coming from the collector—every attempt to execute a program, modify a file, or
connect to the network—is processed at the core. The security policies are processed first. Execution
prevention is enforced when a file is read or executed. If the process doesn’t violate the execution prevention
policy, the collector watches for any attempts to connect to the network or modify files. The core checks these
actions against the security policy rules and blocks anything that might be malicious. If the process makes a
connection that FortiEDR determines was not malicious, then the application is evaluated by communication
control. First, the process is evaluated based on communication control policy rules. Does the application
have a poor reputation or known vulnerabilities? Is it produced by a blocked vendor? If no rules are violated,
then communication is allowed or denied based on the actions chosen in advance by an admin or console
user. We’ll talk more about that process later.
The reason for the order of operations is that the communication control system is designed to track legitimate
applications, not malware. The applications may be risky or undesirable, but they’re not actually malicious.
Malware is handled by the security policies and tracked via events. Malware applications can be very noisy,
and in some cases very numerous. A single event may include many attempted connections. Eliminating the
malware traffic before it reaches communication control allows users to focus on tracking legitimate
applications.
FortiEDR 4.2 Study Guide
190
Communication Control
DO NOT REPRINT
© FORTINET
Now you will look at some use cases. The first customer is a health care company. A user has installed
LogMeIn, a PC remote control program, even though LogMeIn is specifically prohibited in this environment.
The customer can configure a communication control policy to block all versions of LogMeIn from
communicating. The program is still on the user machine, but it can’t do any harm because it can’t connect to
the network.
The second example is a manufacturing company. A user is running a very old, highly insecure version of
Adobe Acrobat, which you don't want to communicate over the network. The customer can configure rules to
block any application version with a low reputation score or high vulnerability score. This will block this version
as well as any future versions that are found to be unsafe. The customer can also manually block the
undesirable version. This means that communication control will block all communication from this exact
version, but will not block any other insecure application versions. In both cases, the user can continue
running the outdated program; however, without the ability to communicate, the program won’t be able to leak
data. If the user downloads a newer, secure version, it will be able to communicate.
The third example customer is a banking company. A client wants to use an open source or shareware
application. Open source software is not allowed in sensitive areas of the bank because there is a risk that the
software may communicate outbound, leaking secrets. The customer can create a communication control
policy to block the open source application from communicating. The program can still be used, but cannot
communicate over the network.
FortiEDR 4.2 Study Guide
191
Communication Control
DO NOT REPRINT
© FORTINET
Now you will learn about the Communication Control in the management console. Start with a very highlevel overview of the Applications sub-tab. You can access this screen by clicking the Communication
Control tab and choosing Applications. The first thing you’ll notice is the applications list. The applications
list identifies all applications in your organization that have communicated externally. If an application has
never tried to establish a connection, it won’t show up here. Click on an application to view all the versions of
that application that have communicated from your environment. For each application and each of its
versions, you’ll see the vendor, the reputation score, the vulnerability rating, and the first and last dates it tried
to communicate.
To the right, you’ll see the Version Details or Application Details pane, depending on whether you’ve
highlighted an application or a specific version. The application and version, if applicable, are shown at the
top. Below that, you can see the assigned action for the highlighted application or version in each
communication control policy. In this example, you are looking at information about a specific version of
Dropbox, which is allowed in three of the policies shown and denied in one. You can scroll down to see more
policies. Underneath the policies information is the Vulnerabilities pane. If the highlighted version has known
CVEs, you’ll see them listed here. If there are no known vulnerabilities, or you have selected an application
but not a specific version, you won’t see this panel.
At the bottom, you’ll see the Advanced Data pane. Here you’ll see detailed application info as well as details
about which users attempted to communicate with the highlighted application and the destination contacted.
FortiEDR 4.2 Study Guide
192
Communication Control
DO NOT REPRINT
© FORTINET
Take a look at how to navigate the applications list. First, you can sort applications. By default, applications
are listed by the date they were first seen communicating. Click on a column heading if you want to sort by a
different criteria. Then, use the arrows at the top to browse through the list. The applications list displays ten
applications at a time.
You can also filter the applications list to focus on a particular set. Use the status filter at the top left to view
only resolved or unresolved applications, applications with unknown vendors, low reputations, or critical
CVEs, unread applications, or all applications. The advanced filter allows you to customize your filter and
create a rule based on that filter. We’ll talk more about how to do that later in this lesson.
Lastly, you can use the search feature. You can enter a search term right into the search bar, or click on the
gray arrow on the right side of the search bar to do an advanced search. In the Search Applications window,
you can use any combination of the criteria you see in the image on the lower right: application name, vendor,
and version, certificate status, reputation, connection dates, selected action, and so on. When you are done,
click the X in the search bar to clear the results.
FortiEDR 4.2 Study Guide
193
Communication Control
DO NOT REPRINT
© FORTINET
There are two ways you can select an application or version in the applications list: highlighting and selecting
the check box. An item is highlighted when you click on its row: its background turns green. In the example on
this slide, VMware Workstation is highlighted, and within its versions, version 14.0.0 is highlighted. The
Advanced Data pane at the bottom of the tab displays information about the highlighted item—in this case,
the highlighted version. The Version Details pane also refers to the highlighted item. The selected application
and version are shown at the top.
The second way to select items is by selecting the checkbox. Each application and version has its own
checkbox. While you can only highlight one application or one version, you can check as many boxes as you
want, or select the checkbox at the very top of the list to check all the items in the list. Selecting checkboxes
enables the buttons at the top of the list. Checked items can be marked as read or unread, deleted, exported,
or you can modify their assigned action. We’ll talk more about these features later in this lesson.
FortiEDR 4.2 Study Guide
194
Communication Control
DO NOT REPRINT
© FORTINET
Take a closer look at reputation scores. The reputation score is very useful guide when you are deciding
which applications and versions should be allowed to communicate. Each new hash is sent to the reputation
service, which sends back a score on a scale of 1 (bad) to 5 (trusted). The score is displayed in the
applications list, so you can quickly identify potential threats. You can set up rules to block communication
from application versions with low reputation scores.
You’ll notice that each application version has its own reputation score. The application score is based on the
lowest reputation score of its versions. So in this example, you can see that Microsoft Office has a score of 3,
meaning there is mixed evidence about its reliability. Microsoft Office is a well-known and trusted application,
and we can see that it’s signed by Microsoft, so why would it have a low score? Take a look at the versions.
Most of them are rated 5, but one older version, shown at the top of the list, is rated 3. The lowest score is
applied to the application so that management console users are alerted to any potential issues. In other
words, a low-scoring application is a signal that you should check for insecure application versions, but there
may be other versions of the same application that are safe. You can deny communication from a particular
version of an application. In this case, you may choose to block the version with a possible problem, but allow
all the others that are rated 5.
FortiEDR 4.2 Study Guide
195
Communication Control
DO NOT REPRINT
© FORTINET
Vulnerability scores are another great tool for evaluating risks in your environment. Fortinet uses up-to-theminute CVE data to assign a vulnerability score to each application version. Vulnerability scores range from
unknown (no known vulnerabilities) to critical (highly exploitable vulnerabilities). As with reputation scores, the
application’s vulnerability score reflects its most vulnerable version. That’s why in this example, Firefox is
listed as Critical, even though some versions shown here have a high vulnerability score, and others have no
known vulnerabilities. Click on a version to view a list of known vulnerabilities and their severity. In the
example on this slide, one of the versions with critical vulnerabilities is selected. You can see which version is
selected by checking at the top of the Version Details pane. You can see that there are 41 known CVEs.
Remember, vulnerabilities are version-specific, so you won’t see any vulnerabilities if you highlight an
application and not a specific version. If you click on a CVE identifier, you can view all the details about that
CVE on an external website. You’ll notice that not all the vulnerabilities are critical in this case. FortiEDR
bases a version’s score on its most exploitable vulnerability. Again, this draws your attention to potential
problems. A version with at least one critical CVE is rated as Critical, and an application with at least one
critical version will be rated critical. As a reminder, you can only see vulnerability data if you have a Predict
and Protect or Predict, Protect and Response license.
FortiEDR 4.2 Study Guide
196
Communication Control
DO NOT REPRINT
© FORTINET
You can see more details about the highlighted application in the Advanced Data panel. The Application
Info section shows you the following high-level information about the selected application: a brief description,
the first and last connection time, and the process name. If you click on the vertical ellipsis to the left of the
process name, you can search for the application on VirusTotal, or you can search the threat hunting
database by hash or file name.
In the Application Usage section, you can view the total number of connections per day for the selected
application, and the distribution across collector groups. If you click More you can see details, such as the
device names, and you can export it to an Excel file. In the Destinations section, you can view the last five IP
addresses with which the selected application communicated. You can also click More to see a more
complete list of up to 50 destinations, and export the list to a Microsoft Excel file.
FortiEDR 4.2 Study Guide
197
Communication Control
DO NOT REPRINT
© FORTINET
Communication control policies are found in the Policies sub-tab in Communication Control. They
determine whether or not an application or version can communicate. Each policy has a pre-set default action
of Allow or Deny. You can determine a policy’s default action by the icon to the left of the policy name in the
list. A gray icon means the policy allows communication by default. A white icon means the policy denies
communication by default. You can also see the default policy action by clicking on the policy to view its
details. In this example, the Default Communication Control Policy is selected and the default action is
Allow. This policy is one of the three built-in policies. The other built-in policies, the Servers Policy and
Isolation Policy, have a default action of Deny. These are special cases where higher security outweighs
potential productivity inhibitors. Most policies should have a default action of Allow.
For each policy, you can create exceptions to the default action. For example, if the default action is Allow,
you can block individual applications or versions from communicating. You will learn more about this process
in detail later in this lesson.
There are two ways to set an exception. First, you can create policy rules. Rules allow you to automate
communication control. Decide on a set of criteria, and FortiEDR will automatically deny communication from
any application or version, current or future, that fits your criteria. You can configure rules based on reputation
score, vulnerability rating, or vendor. Console users can also manually allow or block applications or versions
as needed. So if an application has a reputation score of three, but it’s on your company’s block list, you can
set it to Deny.
Communication control policies are assigned at the collector group level. Each collector group is assigned to
one policy—by default, the Default Communication Control Policy. A policy can have as many groups
assigned to it as you want. Applications are allowed or denied per policy, so an application may be allowed to
communicate in one policy but denied in another. For example, you might allow a specific application for most
users, but deny it for HR because they handle sensitive data. Again, Fortinet strongly recommends allowing
communication by default in all client policies.
FortiEDR 4.2 Study Guide
198
Communication Control
DO NOT REPRINT
© FORTINET
As you’ve learned previously, FortiEDR comes with three built-in communication control policies: Default
Communication Control Policy, Isolation Policy, and Servers Policy. When you create a collector group,
it is automatically assigned to the Default Communication Control Policy. By default, it allows all
applications to communicate. That default can’t be changed, but you can choose to block communication from
unsafe or undesirable applications or versions.
The second built-in policy is the Servers Policy. This is one of the few cases where communication is denied
by default, because servers require a much higher degree of protection. FortiEDR automatically unblocks
some common applications that are definitely safe, like applications that are signed by Microsoft. Review the
list of applications and allow anything you need to run your servers.
Lastly, there is the Isolation Policy. The Isolation Policy is different from other policies because you can’t
assign collector groups to the Isolation Policy. If a device is infected and put into isolation mode, that
collector it will automatically be assigned to the Isolation Policy, no matter what group it belongs to. Isolation
is another rare policy where Deny is the default setting. Isolation mode is a temporary state intended to
contain any infections until the device has been remediated. This means the device can’t be connecting to the
network trying to spread its infection. You should only allow applications that are needed to investigate and
remediate the device.
FortiEDR 4.2 Study Guide
199
Communication Control
DO NOT REPRINT
© FORTINET
Let’s take a closer look at how policy rules work. As we touched on earlier, you can use rules to proactively
reduce your attack surface. Rules apply to existing applications and to applications that haven’t been installed
in your network yet, even ones that haven’t been developed yet.
Each policy has three rules: one based on reputation score, one on vulnerability rating, and one on vendor.
Rules create exceptions to the default action. That means if a policy allows communication by default, which
should apply to nearly all your collectors, rules can be used to deny unsafe applications or unsafe vendors. If
the default action is deny, like the Servers Policy, rules can be used to allow communication from trusted
vendors.
By default, the reputation and vulnerability rules are disabled. You can enable one or both rules by clicking on
the Disabled icon in the State column. You can toggle between Enabled and Disabled. Editing a rule will
automatically set its state to Enabled.
FortiEDR 4.2 Study Guide
200
Communication Control
DO NOT REPRINT
© FORTINET
Rules have a default configuration, which you can edit as needed. There are a few ways to do this. If you are
editing a rule based on reputation or vulnerability, you can edit it from the Applications sub-tab by using the
Advanced Filter. In the example on this slide, the list is filtered to show only applications whose vulnerability
severity is high or greater. Click Setup rule and you’ll see a dropdown list of all the available policies for that
criteria. For this example, you can choose any policy with a default action of Allow. You can see that the
Default Communication Control Policy is selected. After you select a policy, just click Save and Enable.
Note that each policy has only one rule based on each criteria, so you’re replacing the existing rule criteria,
not creating a new one. In this example, you have changed the vulnerability rule to block anything with a high
or critical vulnerability rating rather than the default setting, which only blocks critical vulnerabilities.
You can also edit a rule from the Policies sub-tab by clicking the pencil icon in its row. You’ll see the
applications list with the Advanced Filter set to display the current rule parameters. Change the parameters
as needed, then click Save and Enable. Be aware that each policy has its own set of rules, so if you created
multiple policies you’ll have to edit them all separately if needed. That means you can apply stricter rules to
groups that require more security.
Editing vendor rules is a different process. You can open the Exclude Vendors window by clicking the pencil
icon in the rule’s row or by selecting Vendor in the Advanced Filter drop-down list. Select the checkboxes
next to each vendor that should be treated as an exception—denied in standard policies or allowed in server
or isolation policies. Each vendor has a Signed and Unsigned checkbox, so you could deny all unsigned
applications for a group that handles sensitive data, or allow only signed applications from trusted vendors in
the Servers Policy.
FortiEDR 4.2 Study Guide
201
Communication Control
DO NOT REPRINT
© FORTINET
How do you create a communication control policy? As we said earlier, create additional policies if you want
to allow different applications for different groups of users—for example, if you want to restrict your finance
department more than your other users. Fortinet also recommends creating a simulation policy to help you
troubleshoot potential blocking issues.
To create a new policy, clone an existing one. Select the checkbox next to the policy you want to clone and
click Clone. The new policy will have the same settings—all the same blocked and allowed applications—as
the original, and you can change the policy rules and actions as needed. Note that you can’t change the
default action for your new policy, so make sure you clone a policy with the desired default action. In almost
all cases, that means you should clone the Default Communication Control Policy or a previously created
clone.
FortiEDR 4.2 Study Guide
202
Communication Control
DO NOT REPRINT
© FORTINET
Just like security policies, communication control policies can be in simulation or protection mode. In
simulation mode, no applications are blocked from communicating. In protection mode, communication is
allowed or denied based on the settings you’ve chosen. Out of the box, policies are in simulation mode. You
can enable them when you’ve finished the tuning phase, which we’ll talk about later in this lesson. The
exception is the Isolation Policy. As we talked about earlier, this policy works differently from the others. One
of the things that are different is its mode, which is permanently set to protection mode. This is to ensure that
infected devices that have been placed in isolation mode are always protected and contained.
Rules also have their own states can be enabled or disabled. Reputation and vulnerability-based rules are
disabled out of the box. That means they are not enforced, regardless of the selected policy mode. When
you’ve decided on the right settings for a policy rule, click the state icon at the end of the row to enable it. It’s a
toggle, so click the disabled icon (gray and white) to enable a rule, or click on the enabled icon (a green
target) to disable it. Once you have enabled a rule, it will be enforced, but only if the policy is in protection
mode. If the policy is in simulation mode, the rule will not be enforced.
In other words, if you want to enforce a rule, make sure its state is enabled and its policy is in protection
mode.
FortiEDR 4.2 Study Guide
203
Communication Control
DO NOT REPRINT
© FORTINET
Now take a look at how to change an action manually. You only need to change an action for an application or
version if it isn’t covered by an existing rule and you want to create an exception. There are a number of
circumstances where this might be needed. First, if an application has no serious vulnerabilities and a
reputation score of 3 or better, but it is on a pre-existing company block list, you would need to manually
change its action to Deny. You would also need to manually change an application’s action to Deny if you
evaluated it during the tuning process and decided to block it, or if you decided to block it in high-security
environments while allowing it in other areas. In the Servers Policy, you need to change an application’s
action to Allow if it is necessary for the server to function, while in the Isolation Policy, you should set an
application’s action to Allow if it is needed for remote investigation and remediation.
You can change an application’s action for a single policy or several at once. Just select the checkbox for the
application to select all versions, or select individual versions, then click Modify Action. For client policies like
the Default Communication Control Policy, where the default action should be Allow, select Deny from the
drop-down list next to each policy where you want to block the selected application or versions. If you select
the application and all its versions, the exception will be applied to all current and future versions. In the
example shown on this slide, all versions of Dropbox and Dropbox Update are blocked from the Finance
policy. Dropbox is not an inherently dangerous application; in fact, you can see in the example on this slide
that the version on the top has a reputation score of 5. In general, it’s a known and trusted entity. But in this
case, we don’t want to allow file sharing applications like Dropbox in sensitive environments like the finance
department, so we’re changing it to deny in that policy. Users assigned to the default policy can still use
Dropbox.
The process for setting exceptions in the Servers Policy and Isolation Policy is the same, except that you
select Allow from the policy drop-down menu rather than Deny.
FortiEDR 4.2 Study Guide
204
Communication Control
DO NOT REPRINT
© FORTINET
The applications report is a great tool for evaluating communication control policies. When you generate a
report, the list will reflect the applications shown in the selected view. For example, if you do a search, the
report will only include the results of the search. The same thing occurs if you filter the list; if you show only
unresolved applications, the report will only show the unresolved applications. You can also manually select
checkboxes for specific items to export a small set of applications. If you want a complete report, set the filter
to All, clear any search results, and uncheck any applications. After you have got the list you want to export,
click Export at the top of the applications list and choose a format. You can export to PDF, Excel, or JSON.
You’ll see a pop-up window showing the progress. Once your report is ready, click the blue Download link
and save it to your hard drive.
FortiEDR 4.2 Study Guide
205
Communication Control
DO NOT REPRINT
© FORTINET
Tuning is the process of deciding what applications to allow or block from communicating. First, decide what
rules to enable. Setting the rules for each policy first will save you manual effort. Rules also apply to future
applications and versions, so they offer proactive protection in addition to saving you time later on. For client
policies, like the Default Communication Control Policy, Fortinet recommends denying communication
from any application with a reputation score of 1-2 or a vulnerability rating of High or Critical. You may
choose to apply stricter rules to policies in high-security environments, but keep in mind that blocking too
many applications may lead to an increase in support calls. You can also set a rule to deny untrustworthy
vendors you may find in your list.
Once you’ve set your policy rules, export a full applications list and go through each item to decide which ones
require policy exceptions. If you have an existing list of applications that are allowed or blocked in your
environment, use it as a guide. First, make sure any unsafe applications are set to deny. This includes
applications with a low reputation score or high vulnerability rating. If you have configured and enabled rules
for your policies, these applications should already be denied.
Next, look at the safe applications. In general, you can allow any application with a reputation score of 5.
However, you should check for reported vulnerabilities. You may need to block specific versions even if the
application is generally safe. Again, you can use rules to do that for you.
Applications with reputation scores of 3, 4, or Unknown require review to balance security and productivity. If
you want to revisit any applications at a later date, make a note on the applications report.
For the Servers Policy, the review process is a little simpler. The default action is Deny, so you need to
determine which applications are needed for the servers to work, and allow only those applications.
Optionally, you can use rules to allow communication from applications from specific trusted vendors.
The Isolation Policy also has a default action of Deny. Fortinet recommends keeping this policy as restrictive
as possible—allow applications only if you need them to investigate and remediate an infected device.
FortiEDR 4.2 Study Guide
206
Communication Control
DO NOT REPRINT
© FORTINET
Now take a closer look at the decision-making process for general client policies. These are the policies
applied to most of your users, where the default action is allow. For each application, ask these questions as
you decide whether it should be allowed or denied. First, is the application on an existing block list or allow
list? If it is, you can use that list to make your decision.
If not, the first thing to look at is the application’s vulnerability rating, if you have access to it. If the rating is
critical or high, deny communication from the versions with known CVEs. Remember, you can configure rules
to do this step for you automatically, so this should just be a double-check.
Next, check the reputation score. Block anything scored 1 or 2, and allow anything scored 5. Again, you can
set rules within your policy to automatically block anything with a poor reputation. If it’s in between, or marked
Unknown, the next question is: Do you trust the vendor? If you do, check whether the certificate is signed. If it
is, you can allow the application. If it’s unsigned, or if you don’t necessarily trust the vendor, then you’ll have to
evaluate the risks and benefits. Are there known risks in allowing the application to communicate? And will
blocking the application from communicating cause any potential productivity inhibitors? Use your judgement.
You may want to research the application online to see if other companies trust it.
FortiEDR 4.2 Study Guide
207
Communication Control
DO NOT REPRINT
© FORTINET
The process for reviewing Servers Policy and Isolation Policy is pretty straight-forward. When reviewing the
Servers Policy, you only need to ask one question—does the application need to communicate to allow the
server to function as intended. If yes, change the action to Allow. If the server can function without it, leave it
at Deny.
The process for reviewing the Isolation Policy is similar. You need to know whether the application needs to
communicate to allow necessary troubleshooting and remediation of infected devices. If the answer is yes,
change the action to Allow. If the answer is no, leave it at Deny.
FortiEDR 4.2 Study Guide
208
Communication Control
DO NOT REPRINT
© FORTINET
To remove an application or version from the to-review list, you must change the status of that item.
After you have reviewed an item and made any necessary policy changes, mark it as resolved. Marking an
item as resolved tells other users that they don’t need to review that item.
To resolve an item, open the Modify Action window. You can open the window by clicking the gray
Unresolved icon beside the application or version or by selecting the checkbox and clicking Modify Action.
You can streamline your workflow by clicking Save and Resolve after you change the action associated with
an item. If you don’t need to change the action, use the same process, but don’t make any changes. You can
type a note, if needed, and click Save and Resolve. Be aware that if the Applications filter is set to show
only unresolved events, an application will not show in the list after you mark it as resolved. If you need to find
it again, you can change the filter to show all.
FCS may also mark a version as resolved after evaluating its reputation and known CVEs. If new
vulnerabilities are discovered, FCS may mark the version as unresolved, putting it back on your review list.
FortiEDR 4.2 Study Guide
209
Communication Control
DO NOT REPRINT
© FORTINET
Like security events, application versions are marked as read after you view their details. Unread applications
are displayed in bold, while read applications are in plain text. An application is marked as read when all its
versions have been read. You can change the status of an item by selecting its checkbox and selecting
choose Mark as read or Mark as unread in the Mark As drop-down list. For example, you might want to
mark an application as read without clicking on every version, or you might mark an application as unread if
you want someone else to look at it.
FortiEDR 4.2 Study Guide
210
Communication Control
DO NOT REPRINT
© FORTINET
Now that you know more about how communication control works, you will review the communication control
troubleshooting process. If a user calls the help desk about a connection problem with a specific application,
check for a communication control policy that could be denying communication. There are several ways to do
that. First, you can use the advanced search feature in the Applications sub-tab. Click on the gray arrow on
the right side of the search bar to open the Search Applications window. Set the Action to Deny. In the
Policy drop-down list, select a policy. If you don’t know the policy assigned to the user’s collector group, you
can leave that field empty. To view only applications affecting a specific user, enter the collector name (the
device name) in the Collector field. In the example at the top right, you can see a search for any application
set to deny and affecting the specified device. If you know the application name or version number you’re
looking for, you can enter that in the Search Applications window as well.
Alternatively, if you know the application you want to investigate, you can find the application in the
applications list. You can browse the list, or type the application name into the search bar to find it quickly.
Click on the application row to highlight it. The Application Details section shows the selected action for the
highlighted application in each of the communication control policies. In the example shown on this slide, you
can see the application details for Google Drive File Stream. It’s set to Allow in the Default Communication
Control Policy and the Acme Finance policy, but Deny in the Isolation Policy and Servers Policy, which
deny applications by default. Remember that an application may be allowed to communicate in some versions
but not in others.
If you know the policy you want to investigate, you can also use the Affected Apps column in the Policies
sub-tab to get a list of applications set to Deny. If you click Total X denied apps, (in the example, Total 8
denied apps) you will see the list of applications set to Deny in the Default Communication Control Policy.
The number shown in this link changes according to the number of listed applications.
FortiEDR 4.2 Study Guide
211
Communication Control
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
212
Communication Control
DO NOT REPRINT
© FORTINET
This slide shows all the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to configure and manage communication
control policies and rules.
FortiEDR 4.2 Study Guide
213
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
In this lesson, we will discuss how the FortiEDR next-generation antivirus (NGAV) engine works with postexecution policies to protect endpoints.
FortiEDR 4.2 Study Guide
214
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives on this slide.
By demonstrating competence in understanding NGAV and how it works, you will be able to understand how
security policies protect your system, and schedule device scans.
FortiEDR 4.2 Study Guide
215
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
What is NGAV? It’s the first line of defense. Execution Prevention—the FortiEDR NGAV policy—picks up all
the simple or known attacks and stops them before they execute.
The FortiEDR NGAV engine is powered by machine learning. Our research team feeds millions of preclassified samples of good and bad files and real-world malware into the NGAV engine. It then generates an
algorithm to determine whether or not a file is likely safe or malicious. In comparison, a signature-based
system can only load a small number of the signatures at a time, and it can’t detect malware it’s never seen
before.
Samples are added to the NGAV engine on an ongoing basis so that the algorithm stays up-to-date. You
receive these updates through regular content updates, which you can upload to the console.
FortiEDR 4.2 Study Guide
216
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
How does NGAV work? When a file is saved, read, or executed on a device, the collector checks it against
the NGAV engine. FortiEDR examines the file in real time and assigns it a score based on the likelihood that
the file is malicious. The higher the score, the more likely it is that the file is malicious. Any score above 90%
means there's a high certainty that the file is malicious. Based on the assigned score, the NGAV engine
decides whether to allow, block, or log the file. This process works whether or not the collector is online.
When the collector is offline, it goes into autonomous mode, and it decides how to handle files independently.
FortiEDR 4.2 Study Guide
217
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
Coalfire has validated that the FortiEDR (formerly enSilo) is PCI DSS and HIPAA compliant. So you don’t
need to buy a separate antivirus program; one agent gives you NGAV and post-infection protection.
FortiEDR 4.2 Study Guide
218
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
FortiEDR has four different security policies. The first is our NGAV policy, Execution Prevention. This policy is
where the NGAV engine assigns a confidence score to each file based on how likely it is to be malicious. If
the score is high, it triggers the Malicious File Detected rule. By default, if a file triggers the Malicious File
Detected rule, the file will be blocked from executing. If the score is a bit lower, it triggers the Suspicious File
Detected rule. By default, these files are also blocked. A medium score triggers the Unconfirmed File rule.
These files are allowed to execute, but FortiEDR creates a log in the management console.
Next, we have the two post-infection protection policies. The Exfiltration Prevention policy determines whether
a request to establish a connection is legitimate or malicious. The Ransomware Prevention policy detects and
blocks malware that tries to prevent or limit users’ access to their own systems.
Lastly, we have the Device Control policy. In some industries, there are strict rules about what types of USB
devices can connect to user machines. This policy allows you to select one or more of 23 classes of USB
devices to block. If you don’t need to control USB access to devices in your environment, you can leave the
policy rules disabled.
FortiEDR 4.2 Study Guide
219
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
To get a better understanding of how the Execution Prevention policy works within the FortiEDR system, let’s
review how security policies work. Each policy is made up of a set of rules. Each rule is an indicator of
possible malicious activity. For example, you can see the rules in the Execution Prevention policy. When
FortiEDR detects a violation of one or more of these rules, it creates an event in the management console,
which you can review in the Event Viewer tab. Each rule is assigned an action—either log the event or block
it. Less serious rules are set to Log. These are rules that could be triggered by a legitimate process, but are
also sometimes used by malware. You might want to take a look at the event just to be sure, but the policy
allowed it to continue.
Again, each policy is enforced at a different time. NGAV is first—it detects violations when a malicious file is
read or executed, either by the user or the operating system. If a file is blocked by the Execution Prevention
policy, it doesn’t execute. Exfiltration Prevention detects violations when there’s an attempt to establish a
connection. Ransomware Prevention detects violations whenever there’s an attempt to lock files or modify
data.
If a process is blocked by an Execution Prevention Policy rule, it can’t try to establish a connection or modify
data. So, it’s never checked by Exfiltration Prevention or Ransomware Prevention.
Note that if you choose to enable Device Control, it will operate in parallel to these policies. Rather than
looking for malicious behavior, it is watching for specific device classes attempting to access your computers.
FortiEDR 4.2 Study Guide
220
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
Here’s another way to look at the order of operations. Again, the Execution Prevention policy is the first line of
defense. If there’s a violation, the file is blocked. If it gets through, post-infection protection kicks in. The
Ransomware Prevention policy watches for any attempts to lock or modify files, and the Exfiltration
Prevention policy watches for attempts to establish a connection. If either one of these policies detects a
violation, the process is blocked. If no security policy rules are violated, the file is checked by communication
control when it attempts to connect to the network. As we discussed in earlier lessons, communication control
manages programs that aren’t malicious, but may be undesirable or insecure. If a file gets through to the
communication control engine, we’ve already determined that it’s not actually malware.
FortiEDR 4.2 Study Guide
221
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
One of the requirements for antivirus replacement certification is to allow users to schedule periodic scans of
all their devices so they can find and remediate dormant threats. Remember, your computers are constantly
being monitored by the collector, so you don’t actually need to schedule scans, but if you want to, the
functionality is available in the Administration tab of the management console, under Tools. You can select
your preferred time and frequency, and the files will be scanned in the background. The scan uses a small
amount of resources on the device.
FortiEDR 4.2 Study Guide
222
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
223
Next-Generation Antivirus
DO NOT REPRINT
© FORTINET
This file shows all the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned how the FortiEDR NGAV policy works.
FortiEDR 4.2 Study Guide
224
Threat Hunting
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use threat hunting to find and remove malware across your environment.
FortiEDR 4.2 Study Guide
225
Threat Hunting
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives on this slide.
By demonstrating competence in threat hunting, you will be able to find and delete instances of known
malware in your environment.
FortiEDR 4.2 Study Guide
226
Threat Hunting
DO NOT REPRINT
© FORTINET
The threat hunting module records the details of every executable file on every device in your organization.
Management console users can then search the entire environment for a malicious file, by name or hash, and
remove the threat.
Threat hunting allows management console users to find dormant threats before they execute and remediate
them. Essentially it’s a search and destroy operation. Threat hunting also helps you unravel the story behind
an attack—who was patient zero, who else was attacked, and so on.
FortiEDR 4.2 Study Guide
227
Threat Hunting
DO NOT REPRINT
© FORTINET
Every time a file is read, modified, or executed on a device, the collector sends several properties of the file to
the threat hunting repository through the core. The threat hunting repository stores information about many
executable file types, such as exe, dll, and so on. For each executable, it stores the name of the collector, as
well as the file’s hash, name, creation time, modification time, size, properties, and details like the vendor and
version number. You can search the repository by file name or hash. When you find a malicious file, you can
delete it from any device, right from the management console.
FortiEDR 4.2 Study Guide
228
Threat Hunting
DO NOT REPRINT
© FORTINET
The first thing you need to use threat hunting is a license. Threat hunting is not included in all FortiEDR
license types.
Next, you’ll need a threat hunting repository server. The server needs to have at least 8 GB of memory and
200 GB of available disk space. For more details about server requirements, see the FortiEDR Installation and
Administration Guide. Install the threat hunting repository before installing the central manager and
aggregator. You’ll need to enter the threat hunting repository’s IP address and login credentials when you
configure the central manager. Every environment should have its own threat hunting repository server.
FortiEDR 4.2 Study Guide
229
Threat Hunting
DO NOT REPRINT
© FORTINET
Now, you will walk through an investigation using threat hunting. In the Event Viewer, find the malicious event
that you want to investigate further. The example on this slide shows a file called Windows.UI.exe. You can
see from the action icon to the right of the event row that the device was in simulation mode, so you must
make sure you clean everything up thoroughly. Select the checkbox next to the event, and then click the
Forensics button above the events list. You may remember from an earlier lesson that you always have to
click the Forensics button to load an event. If you click the Forensics tab, it will open, but it won’t load the
event you want to investigate.
FortiEDR 4.2 Study Guide
230
Threat Hunting
DO NOT REPRINT
© FORTINET
Now, you will investigate the file hash. This helps you determine what you’re dealing with, particularly when
you’re dealing with an unfamiliar threat, and it also double checks that you’re investigating the malicious file
and not another file that was involved in the event.
At the upper-left, you’ll see the event in the Forensics tab. You can click a node to see its stack details. Start
by clicking the first node. In the Stacks view, the selected stack is shown in red underlined text in the stacks
toolbar, as this slide shows on the left side of the middle image. The process hash for the selected stack is on
the right side of the Stacks Details pane. Click the three vertical dots to the left of the process hash and
select VirusTotal. This opens the hash in VirusTotal, so you can see the file’s reputation and which security
programs identified it as malicious. You can see the results on the lower right. You’ll notice that zero out of 66
security programs flagged it as malicious. Does this mean it’s a false positive? Take another look at the
Forensics tab. The process hash always corresponds to the source process, not the target process. On the
left side of the Stack Details panel, you can see the source process is explorer.exe. This probably means
the user launched the file from Windows Explorer, so while it was involved in the chain of processes that
caused the event, it wasn’t the problem. Next, you will find the correct file.
FortiEDR 4.2 Study Guide
231
Threat Hunting
DO NOT REPRINT
© FORTINET
Take another look at the Stacks toolbar. The stack shown with a red dot is where the rule violation occurred,
so that’s where you’ll find your malicious file. In the image on the top right, you can see that the source
process down at the bottom is Windows.UI.exe. Click the vertical dots again and select VirusTotal. On the
lower right, you can see the results, and they look more like what you were expecting—55 out of 67 security
programs flagged this hash as malicious.
FortiEDR 4.2 Study Guide
232
Threat Hunting
DO NOT REPRINT
© FORTINET
Now that you know you’ve got the right file and have confirmed that it’s malware, you can start threat hunting.
Click the three dots next to the hash, just like before, and select Threat Hunting from the options. You’ll see
the Threat Hunting tab showing a list of all instances of the hash in your environment. In this case, you can
see there are two infected devices.
Also, notice the timeline at the top—you can limit the search period, or you can search for the maximum
period available. Just make sure that the search window isn’t too narrow. If you’re trying to find all variants,
you’ll probably want to search over a wide time period.
FortiEDR 4.2 Study Guide
233
Threat Hunting
DO NOT REPRINT
© FORTINET
In some cases, it’s useful to find patient zero, the first system to get infected with this piece of malware in your
environment. All you need to do is click the Creation Time heading to sort by the first instance of the hash on
each device. The one at the top is the first infection to appear, so that’s your patient zero.
FortiEDR 4.2 Study Guide
234
Threat Hunting
DO NOT REPRINT
© FORTINET
Now, delete the malicious files from the user devices. You can do this right in management console. Select
the checkboxes for all the devices you want to remove the file from, and then click the Remediate button at
the top of the tab. Note that you can only remove the file if the device is currently online. Once you’ve clicked
Remediate, confirm, and FortiEDR will remove the file. It’s important to be aware that remediating a device in
threat hunting won’t stop any processes that are already running. If a device was involved in a security event,
make sure you fully remediate it. The Remediate button on the Forensics tab gives you more ways to
remediate an attack that has already started, including stopping a process and cleaning the registry.
FortiEDR 4.2 Study Guide
235
Threat Hunting
DO NOT REPRINT
© FORTINET
In some cases, there may be variants of a malicious file that use different hashes. To find them, click the File
Name button to change the search type, then enter the name of the executable you’re investigating—in this
case, Windows.UI.exe. Click the Search button on the right, or press the Enter key. The example shown
on this slide shows that there are no versions of this file that have a different hash.
Be aware that malware files may disguise themselves by using a filename associated with a legitimate
program or process. Make sure you investigate variants before deleting them.
FortiEDR 4.2 Study Guide
236
Threat Hunting
DO NOT REPRINT
© FORTINET
You can also use threat hunting to check for new threats you’ve heard about. You may belong to an industry
consortium that periodically sends emails alerting you to a new malware threats. In this scenario, you’ve
received one of these alerts, and you want to check your network to see if any devices are infected. Click the
Forensics tab and select Threat Hunting. Click the File Name button in the upper-right corner of the screen
to search by name, then type the name of the file you’re concerned about. Click Search, or press the Enter
key. You’ll see a full list of the executable in your system. The example on this slide shows a search for
locky.exe, an older threat, and found a number of instances of the file. You can delete the files the same
way you did on the previous slide. Just remember to check the Event Viewer as well—any devices that
triggered an event may require additional attention.
FortiEDR 4.2 Study Guide
237
Threat Hunting
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
238
Threat Hunting
DO NOT REPRINT
© FORTINET
This slide shows the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to use threat hunting to find and remove
malware across your environment.
FortiEDR 4.2 Study Guide
239
RESTful API
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use RESTful API with FortiEDR.
FortiEDR 4.2 Study Guide
240
RESTful API
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives on this slide.
By demonstrating competence in RESTful API, you will be able to use RESTful API to interact with the
FortiEDR management console.
FortiEDR 4.2 Study Guide
241
RESTful API
DO NOT REPRINT
© FORTINET
What is the API? You can easily integrate FortiEDR’s functionally into your organization's existing software.
The FortiEDR central manager supports REST HTTP-based API for accessing security and communication
control data, as well as device and software configuration and operations. Essentially, it’s a way of
programmatically duplicating the functionality of the management console. You can manage device and
software configuration, analyze events, and remediate devices, all without having to go through the
management console.
FortiEDR 4.2 Study Guide
242
RESTful API
DO NOT REPRINT
© FORTINET
How does RESTful API work? It’s REST-based over HTTP. It uses SSL encryption, and it passes back
protocol information in JSON format. You can use either token or password-based authentication. To use
password-based authentication, you need to make sure that the user is assigned the Admin and Rest API
roles. You can do that in the Administration tab of the management console under Users. The API uses a
few different methods—GET to read data, POST or PUT to update. It also has DELETE and a few others. You
will learn about methods later in this lesson.
FortiEDR 4.2 Study Guide
243
RESTful API
DO NOT REPRINT
© FORTINET
There are a couple of ways to access the API. The first method is to use Curl, which you can do on the CLI.
This slide shows a typical Curl request. If you’re using a self-signed certificate for your central manager, which
is the default setting, use -k to bypass the certificate verification. Enter -H followed by the authorization type
and credentials, then enter the URL parameters. The example command returns a list in JSON format
containing all the events in your environment.
The second method is to use the Postman app. Postman is a free application available for download. In the
lower left corner of the example shown on this slide, you see the same request you just saw in Curl, but
formatted for Postman. First, select the GET method, then enter the URL parameters: https://<FortiEDR
host>/management-rest/events/list-events. In the image on the slide, you can see a command in
the app itself. You can see GET at the top left, then the URL parameters—in this example, you’re asking for a
list of all the organizations in a multi-tenant environment. Below that, you can see the Authorization tab.
Choose Basic Auth from the TYPE drop-down list, and enter a Username and Password. You’ll learn more
about authentication on the next slide. At the bottom, you can see what came back from that request—a
JSON file listing all the organizations. You can see the organization name, allocated seats, seats in use,
expiration date, and so on.
FortiEDR 4.2 Study Guide
244
RESTful API
DO NOT REPRINT
© FORTINET
Now you’ll learn more about API credentials. Postman allows you to enter your username and password in the
Authorization tab. You saw what that looks like on the previous slide. If you want to do it in Curl, enter
username:password, with base-64 encryption. So, it would look something like this: curl -k -H
“Authorization: Basic” followed by your encrypted credentials.
If you prefer to use API authorization tokens, you’ll receive a token when you send a request using your
username and password. On the right side, you can see the Headers tab of the Postman app after you’ve
sent a request using a username and password. You can see at the bottom that there is an X-Auth-Token.
You can copy that token and use it in future requests instead of your username and password.
FortiEDR 4.2 Study Guide
245
RESTful API
DO NOT REPRINT
© FORTINET
Why use Postman? It’s a very easy way to interact with the API—it’s a clean and simple interface, and it
saves API request history, so you can have a working list of what you've done previously, and you can reuse
a request to save you from having to enter in all the information again.
Here are a few tips on using Postman. First, make sure you select the correct request method on the left side
of the screen. In the example shown on this slide, you can see a PUT request. Next to that are the URL
parameters. You’ll learn more about body parameters later in this lesson. You can also consult the FortiEDR
RESTful API Guide for a complete list of options. Some request types require body parameters. In that case,
select the Body tab, select raw, and then select JSON format from the drop-down list on the right side of the
screen. Then you can type your body parameters into the text field. The example shown on this slide changes
the status of event 51516.
FortiEDR 4.2 Study Guide
246
RESTful API
DO NOT REPRINT
© FORTINET
Take a look at an example workflow using the API. In this scenario, you’ll be investigating threats in a
FortiEDR environment. First, you need a list of events classified as malicious or suspicious and with an action
of block or simulation block.
At this point, you’re retrieving information rather than changing anything, so you’re using the GET method.
Then you’ll enter the URL parameters. You’ve seen a few examples already, but this time you’re looking for a
list of events, so start with https, then enter your FortiEDR host. You can use the IP address or the name:
for example, acme.fortiedr.com. After the host address, always enter management-rest followed by
the category, events, and then the call—in this case, list-events. Then you’ll add the search criteria. You
can search for multiple search parameters at once by using an ampersand in between parameters. In this
case, you’re searching for classifications and actions. You can also enter multiple values for each
criterion by separating them with a comma. In this case, we’re looking for two possible classifications and two
possible actions.
This search returns a list in JSON format. There is quite a bit of information about each event—the event ID,
process, path, dates, status, which rules were violated, and so on. To continue the example workflow, let’s
say we’re investigating the event shown on this slide. Note the event ID, 22752. Next, you’ll use that ID in a
new request.
FortiEDR 4.2 Study Guide
247
RESTful API
DO NOT REPRINT
© FORTINET
Now get the raw event details for the event ID you just copied. You’ll send another GET request, this time
asking for the raw data items for the event ID, and then add fullDataRequested=true.
Again, you’ll receive a JSON list, this time showing the details about the raw items. Use this information to
retrieve the executable. To do that, you’ll need the raw EventId, MainProcessId, and the Application path.
Copy each of these values into a separate text file so you can use them later to retrieve a sample of the
malware. There are a couple of things to remember. First, the EventId field here is not the same as the event
ID you copied in the previous slide. This is the raw event ID, which is what you need to retrieve the file. Also, if
you look at the application path, you’ll notice that there are extra backslash characters. You need to remove
those from the path so it looks like a regular path, like you see in the example in the lower-left corner of the
screen.
FortiEDR 4.2 Study Guide
248
RESTful API
DO NOT REPRINT
© FORTINET
Now use the information you just got to retrieve the executable using a GET command. Then enter the URL
parameters. In this case, you’re looking for information stored in forensics, so change the parameters to
forensics, followed by the get-event-file command. Then use the information you just copied—the
raw event ID, process ID, and application path—to tell the system exactly what file you’re looking for.
If you click Send, your results will look something like what you see in the upper-right area of the screen. It
looks like gibberish, but it’s actually a password-protected zip file containing the file you requested. To get that
file in a usable format, you use Send and Download. Use the Send drop-down menu to select Send and
Download. Now you can save the zip file locally. To extract the executable, enter the password—
enCrypted, with a capital C.
FortiEDR 4.2 Study Guide
249
RESTful API
DO NOT REPRINT
© FORTINET
After you’ve retrieved the executable, evaluate it by testing it in a secure sandbox environment. For example,
say you verify that the file is malicious. You might want to put the affected collector into the High Security
Collector Group to contain the infection until you fully remediate the device. To do that, send a PUT
command. You’re sending information related to inventory, so enter inventory/move-collectors. Then
enter the collector name and the target group—in this case, the High Security Collector Group. You can
verify the result in the management console. The example on this slide shows you that you successfully
moved cwin7-32 from the Default Collector Group to the High Security Collector Group.
FortiEDR 4.2 Study Guide
250
RESTful API
DO NOT REPRINT
© FORTINET
Next, remove the malicious executable from the user’s device. You can do this using a PUT request. This is a
forensics function, so enter forensics/remediate-device. Then, specify the device name and the name
and path of the executable you want to remove, using the format you see here. The file should disappear from
the device, as the example on this slide shows.
FortiEDR 4.2 Study Guide
251
RESTful API
DO NOT REPRINT
© FORTINET
After you remediate the device or create an exception, mark the event as Handled so that other management
console users know you’ve already dealt with it. You can also mark it as Read. To change the event status,
send a PUT request. You must modify the event in the events category. Then, you must specify the event
ID. This time, you must complete the body field. Set read to true and handle to false, meaning the event
is no longer to handle. It’s always a good idea to add a comment explaining how you handled the event and
any other relevant information. You can verify your changes in the Event Viewer tab of the management
console. In the image on this slide, you can see that the event is Handled and your comment has been added
to the Event Handling window. If you look closely, in the background you can see a light-colored flag, which
indicates that the event has been handled, and the event is in plain text, meaning it is marked as read.
FortiEDR 4.2 Study Guide
252
RESTful API
DO NOT REPRINT
© FORTINET
This slide shows an alternative scenario. Say you examine the file that triggered an alert and find that it isn’t
malware. In that case, you might want to create an exception. You can do that through the API as well. Use a
POST command. In the events category, in the URL parameters, enter events/create-exception.
Then, you must specify the exception parameters—the event ID it applies to, then the collector groups you
want to apply the exception to, which, in the example shown on this slide, is the Sales Group, and not all
collector groups. We can also specify destinations. The example shown on this slide shows that the exception
doesn’t apply to all destinations; the process can communicate with only a specific IP address and internal
destinations.
You can also use the Body field to enter more specific parameters. This is what you’d see in the Advanced
field of the Exception window if you were using the management console. For more information, see the
FortiEDR RESTful API Guide.
FortiEDR 4.2 Study Guide
253
RESTful API
DO NOT REPRINT
© FORTINET
You can also use the API to find and delete inactive collectors. First, you need a list of inactive collectors. This
is a GET request: <FortiEDR host>/management-rest/inventory/list-collectors. Then,
narrow the list parameters to collectors in a Disconnected state that were last seen before the specified
date—in this case, September 1, 2020. Use the following format: yyyy-mm-dd, then the time, using the 24hour clock: h:m:s. Your results will look something like what you see in the middle of the column on the right
side of this slide. You’ll see data for each collector that fits your search criteria. Look through the list to make
sure it looks right. For example, if you were expecting three or four collectors and got 50, you should make
sure you entered your parameters correctly. Once you’re confident that your list is correct, delete the inactive
collectors. The request type is DELETE. Enter <FortiEDR host>/managementrest/inventory/delete-collectors. Then, specify the collector state (Disconnected) and the last
seen date (before 2020-09-01).
Remember that deleting collectors doesn’t uninstall them, it just removes them from the management
console. If the collector reconnects, it will reappear in your collector list.
FortiEDR 4.2 Study Guide
254
RESTful API
DO NOT REPRINT
© FORTINET
Take a look at some basic API troubleshooting, starting with user login problems. One of the most common
issues reported is an unauthorized message when a new user tries to use the API for the first time. The
reason for this is the password reset requirement. New users are forced to change their passwords the first
time they log in to the management console. Since you can’t reset your password with the API, you get an
error message. The solution is pretty simple. To resolve this issue, in the management console, in the
Administration tab, click Users. Find the user in the list and click Reset Password. The Reset Password
dialog opens. Clear the Require a change of password at the next sign-in checkbox, then enter the
password and click Reset. The user should now be able to log in through the API. Alternatively, you can ask
users to log in to the management console and reset their password before using API calls.
FortiEDR 4.2 Study Guide
255
RESTful API
DO NOT REPRINT
© FORTINET
Another error you might see is that your request returns the message Could not get any response.
This can be caused by a number of issues but, in this case, it’s usually the SSL verification setting. By default,
Postman is configured to verify SSL certificates. Since many FortiEDR environments use self-signed SSL
certificates, Postman isn’t able to verify the certificate, so it blocks the connection. This is the same issue that
causes the security errors you sometimes see when you log in to the management console. In the Postman
window, in the upper-right corner, click the wrench icon, then click Settings. In the Settings window, under
Request turn off SSL certificate verification, then close the window. Try your request again and you should
get a connection.
FortiEDR 4.2 Study Guide
256
RESTful API
DO NOT REPRINT
© FORTINET
This slide shows a selection of useful API commands. You can get a full list with detailed instructions in the
FortiEDR RESTful API Guide.
FortiEDR 4.2 Study Guide
257
RESTful API
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
258
RESTful API
DO NOT REPRINT
© FORTINET
This slide shows all the objectives covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to use RESTful API with FortiEDR.
FortiEDR 4.2 Study Guide
259
Multi-Tenancy
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about FortiEDR multi-tenancy.
FortiEDR 4.2 Study Guide
260
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 understand how multi-tenancy
works and how it can benefit your organization.
FortiEDR 4.2 Study Guide
261
Multi-Tenancy
DO NOT REPRINT
© FORTINET
So, the first question is, why multi-tenancy? The primary use case is to manage multiple organizations from a
single management console. If you are an MSP managing multiple organizations, you don't have to log in to
10 or 12 twelve different consoles—you can log in to one or two and be much more efficient and effective. You
can assign collectors and threat hunting repositories to an organization, and you can also assign cores to
individual organizations. You can manage policies, groups, and collectors from all your organizations in one
place. Hosters also have the ability to view an individual organization’s data, or see aggregated data for all
organizations.
If you’ve been hosting multiple organizations on a single console, multi-tenancy also allows you to give
administrators from a single organization access to their own console. Previously, client administrators
couldn’t access their own alerts in this scenario because their alerts couldn’t be separated from the alerts of
other customers. Now you can let administrators log in and view only their own organization’s data.
FortiEDR 4.2 Study Guide
262
Multi-Tenancy
DO NOT REPRINT
© FORTINET
There are three levels of users in a multi-tenant environment . The first role is the Admin . This is the top-level
administrator for the host environment. The Admin can access global data as well as all of the organizations in
the environment. Next, is the Local Admin. The Local Admin can administrate everything in their
organization, but can’t see any other organizations. Then, within the organization, is the User. A User can do
everything a Local Admin can do except access the Administration tab.
FortiEDR 4.2 Study Guide
263
Multi-Tenancy
DO NOT REPRINT
© FORTINET
As you learned on the previous slide, your user level determines what you can do on the management
console. If you're an Admin, you can create, modify, and delete organizations, and you can view and manage
system components, events, and policies for all organizations. You can see all the organizations in your
environment, as well as global data. Going forward in this lesson, Admin will always refer to the hoster Admin.
A Local Admin can view and manage system components, events, and policies assigned to their own
organization, as well as administrative settings for their own organization, but they can't see or do anything
outside of their own organization. This role is essentially the same as the Admin, except it’s limited to a single
organization.
Then finally, a User can also view and edit single organization data, but can't see or access the
Administration tab. That means they can view and modify security events, policies, communication control
and inventory, but they can’t retrieve the registration password, edit the end-user notification settings, create a
new console user, or any of the other functions found on the Administration tab.
FortiEDR 4.2 Study Guide
264
Multi-Tenancy
DO NOT REPRINT
© FORTINET
In a multi-tenant environment, you will see a new Organization name field. When logging in to a multi-tenant
environment, users must enter the name of their assigned organization as well as their User name and
Password. The organization name is case sensitive, so be sure to tell management console users exactly
how to enter it. If this field is left empty, the user will be logged in to the default organization, if their
permissions allow. In a single-tenant organization, the organization field doesn’t appear.
FortiEDR 4.2 Study Guide
265
Multi-Tenancy
DO NOT REPRINT
© FORTINET
If you're set up as the hoster Admin, you have two types of views to choose from. The first is the Hoster view.
This allows you to view aggregated data from all organizations, including security events, exceptions, security
policies, system components, and administrative data. Hoster Admins can also drill down into a specific
organization by selecting it from the drop-down list on the upper left. In the Organizations view, you can see
data specific to a particular organization, including security events, exceptions, application usage data,
aggregated application data, security policies, system components, and administrative data for the selected
organization.
FortiEDR 4.2 Study Guide
266
Multi-Tenancy
DO NOT REPRINT
© FORTINET
On the Organizations pane of the Administration tab, you can create and edit organizations. Allocate
license seats for each organization, including the number of workstations, servers, and IoT devices that are
allocated to the organization. You can also set or change each organization’s license expiration date. Be
aware that license seats and expiration dates are contingent on the hoster organization’s license with Fortinet.
You'll learn more about that on the next slide.
In multi-tenant environments, registration passwords are organization-specific, so they’re part of the
organization settings as well. If needed, you can delete organizations. Note that you can’t delete an
organization without removing all the collectors assigned to it, either by deleting them from the system or
moving them to another organization. You can also import an organization from another environment using
the migration tool.
This pane can be viewed only by hoster Admins.
FortiEDR 4.2 Study Guide
267
Multi-Tenancy
DO NOT REPRINT
© FORTINET
You’ll see the Organization Details dialog box when you create a new organization or edit an existing one.
Only hoster Admins can assign and edit organization details. First, you’ll see the organization’s name. You’ll
use the name to assign collectors to the organization during installation and to move existing collectors to the
organization. Local Admins and users will also use the organization name to log in to the management
console. Remember that the organization name is case-sensitive when you log in to the console, so make
sure all users know exactly how their organization is entered here. Organizations are also assigned a unique
ID in the background, so you can change the name if you need to without affecting the collectors assigned to
the organization.
Next you have the Registration Password. Again, this is organization-specific, and it allows organizations to
validate collector installations and uninstallations. This makes it harder for malware to disable or remove the
collector, and also prevents users from uninstalling the collector accidentally.
Each organization’s license also has an assigned expiration date. Be aware that if you assign an expiration
date that is after the hoster’s license expiration date, the earlier date will take precedence. In other words, if
an organization’s license expiration date is set at December 2021, but the hoster’s license expires in June
2021, the organization will only be protected until June 2021 unless the hoster organization extends its
contract.
FortiEDR 4.2 Study Guide
268
Multi-Tenancy
DO NOT REPRINT
© FORTINET
Lastly, you can see the organization’s license capacity. Each organization must be allocated enough license
seats to accommodate all the collectors you plan to install or move into the environment. You’ll need
workstation licenses for most devices, and server licenses for collectors installed on a server or a Linux
machine. Assign IoT device seats to track IoT devices, like printers, smartphones, and media devices, that
connect to your network.
Note that the total number of seats available is determined by the hoster's license agreement with Fortinet, so
if your agreement was for 10,000 workstation licenses, you can’t allocate 20,000 to an organization without
contacting Fortinet to update your license. The total available seats remaining is shown on the Licensing
pane of the Administration tab, but you can also see it in the Organization Details dialog.
Note that, by default, all seats are assigned to the default hoster organization, so before you add more
organizations, you must decrease the default organization's license allocation in order to free up seats to be
assigned to other organizations.
FortiEDR 4.2 Study Guide
269
Multi-Tenancy
DO NOT REPRINT
© FORTINET
Once you’ve created an organization on the Administration tab, you may need to move existing collectors
into that organization. You won’t need to do this for new collectors—you can assign them an organization
during installation. You'll learn more about that later in this lesson. But if you’re upgrading, switching from a
single-tenant environment to multi-tenant, or didn’t install your collectors with the organization specified, all the
collectors will be in the default organization for your hosting platform and you’ll need to reassign them as
needed.
Before you migrate any collectors, make sure you’ve set up collector groups in each new environment . You’ll
already have the built-in High Security Collector and Default Collector groups, but if you want to organize your
users, you can save time by configuring them now. To do this, you must select your new organization from the
drop-down list in the upper left if you’re a full Admin. Local Admins and Users will not see this drop-down list
because they are allowed to view only their own environment. On the Inventory tab, select Collectors, then
use the Create Group button to add as many groups as you need. You also must assign security policies,
communication control policies and playbooks to each group so that they continue to be protected. You
learned about assigning policies in an earlier lesson—you can do it on the Security Settings and
Communication Control tabs.
There are a couple of other things to be aware of when moving collectors. First, only hoster Admins can move
collectors between organizations. Local Admins and Users can’t see collectors unless they’re already
assigned to their organization, so they can create collector groups and move collectors between groups, but
can’t move them from a separate organization.
FortiEDR 4.2 Study Guide
270
Multi-Tenancy
DO NOT REPRINT
© FORTINET
Now that your organization is configured, you’ll learn about the process of moving the collectors. Moving
collectors to an organization works very much like moving them to a new collector group. On the Inventory
tab, select the Collectors sub-tab. Find the collectors you want to move, select their checkboxes, then click
the Move to group button. In the Collector Groups dialog box, you’ll see the Organization drop-down list at
the top. Select the target organization, then select a collector group from the list shown, and click Move to
Group. FortiEDR will update the collectors with an organization ID and a new registration password. The
collector then registers itself to the new organization. Note that the target organization needs to have enough
remaining license seats to accommodate the collectors you want to move. If you don’t have enough seats,
you can reallocate them in the Organization Details dialog box you saw earlier in this lesson.
FortiEDR 4.2 Study Guide
271
Multi-Tenancy
DO NOT REPRINT
© FORTINET
If you have multiple FortiEDR environments, you might want to move an organization from one to another—for
example, from a POC environment to a customer environment. You can do that on the Administration tab
under Organizations. You’ll need Admin permissions for both the source and destination environments.
The first step is to export the organization from the old environment. Click the migration button on the
organization’s row. The Migrate Organization dialog box opens. Enter the name you want to use in the new
environment. You must choose a name that does not already exist in the destination environment. Then click
the Export button. FortiEDR will generate a zip file containing all the organization’s data and destinations.
This may take several minutes, depending on the size of the organization. When the file is generated, click
Download and save the file locally.
Next, you must import the organization into your target environment. On a new browser tab or window, log in
to the destination management console and browse to the Organizations pane of the Administration tab.
Click the Import Organization button, browse to the zip file you downloaded earlier, and click Import. The
import process may take several minutes to complete. Once it is finished, you will see an Import code in the
dialog box under the progress bar. Copy the code. Next, return to the source management console. Paste the
import code in step 2 of the Migrate Organization dialog box. If you closed the dialog box or management
console earlier, you can return to this step by clicking the Continue Migration button in the organization row.
Once you’ve entered the code, click Next to continue.
The final step is migrating the collectors. In step 3 of the Migrate Organization dialog box, enter the
aggregator address of the target environment. Then, click the Transfer button and wait for the transfer
process to complete.
FortiEDR 4.2 Study Guide
272
Multi-Tenancy
DO NOT REPRINT
© FORTINET
When you generate a self-installer, you can specify which organization the new collector should register to.
You can create a custom installer using the Silent Installer Generator or by requesting an installer on the
Administration tab of the management console under Licensing. Note that the installer request feature
requires FCS connectivity. If you use the Silent Installer Generator, remember that the version must match the
collector installer version.
If the installer file specifies an organization, the collector will be added to the specified that organization. If it's
left blank, the collector will be added to the default organization. This field should be left blank in single-tenant
environments. Remember that in multi-tenant environments, the Registration Password is organizationspecific, so make sure you enter the correct password for your organization. Collectors may also be
registered to an organization through command line options.
FortiEDR 4.2 Study Guide
273
Multi-Tenancy
DO NOT REPRINT
© FORTINET
In a multi-tenant environment, cores can either be shared among all tenants, which is typically the case with
cloud-based cores, or they can be allocated to a specific tenant, which is almost always the case with an onsite core. Cores may be added to a specific organization during the configuration process. If the core is global,
or shared, this field may be left blank. If the core is assigned to a specific organization, collectors in other
organizations can't communicate with it. An environment may choose to install multiple cores to prevent data
from having to cross firewall boundaries, or to limit traffic across the LAN connection.
FortiEDR 4.2 Study Guide
274
Multi-Tenancy
DO NOT REPRINT
© FORTINET
Now, you’ll take a quick look at how security policies work in a multi-tenant environment. Each security policy
is assigned to a specific organization—there are no global policies. Each organization has at least one of
every security policy type—Execution Prevention, Exfiltration Prevention, Ransomware Prevention, and
Device Control. The Hoster view shows all security policies for all organizations. Admins can create new
policies by cloning an existing one. In the Hoster view, you can clone a policy from one organization to
another, as well as within an organization. Local Admins and Users can only see and modify policies assigned
to their organization. Playbooks work essentially the same way—each belongs to one organization, and each
organization has at least one playbook. Remember, playbooks control when security event notification events
are sent, so it’s important to configure them even if you don’t plan on using the automated investigation and
response features.
FortiEDR 4.2 Study Guide
275
Multi-Tenancy
DO NOT REPRINT
© FORTINET
In version 4.0 and later, you can view events from all organizations in the Hoster view. In the Event Viewer,
you can see all your tenants’ events in one place, and you can analyze any event from any organization in the
Forensics module. Local Users and Admins can view events for their organizations only. Threat hunting is
also available across organizations, so if you identify a malicious file, you can find and remove it from all
organizations in one step.
FortiEDR 4.2 Study Guide
276
Multi-Tenancy
DO NOT REPRINT
© FORTINET
If you analyze an event and find that it’s safe, you can create an exception for a specific organization, or if
you’re an Admin, you can create a global exception. Admins can also take an exception created in a specific
organization and make it global. Local Admins can create security exceptions for their own organizations, and
can view, but not edit, global exceptions.
The best practice is to make exceptions as broad as possible so, in most cases, an organization's exceptions
should be global. If the exception uses an organization's IP sets, however, you can’t make it global because
IP sets are organization specific. For example, any exception applied only to internal IPs or only to AWS IPs
can’t be global.
Note that any comments added to global exceptions can be seen by all organizations, so don’t add any
comments that you don’t want to share with all management console users.
FortiEDR 4.2 Study Guide
277
Multi-Tenancy
DO NOT REPRINT
© FORTINET
Communication control works on a per-organization basis. Currently, there is no global interface for
communication control—if you’re an Admin in Hoster view, you won’t be able to see any communication
control data. Select an organization to view its communication control data. Local Admins and Users see the
communication control data only for their assigned organizations. Communication Control policies are specific
to each organization as well—any customizations, like blocked applications or specialized policies, are not
available to other organizations.
Advanced data is limited for Local Admins. They can see application usage data for their own organization,
but application information and destinations are hidden. The reason for this is that these fields are not
currently available on a per-organization basis. Hoster Admins can see all the data that would be available in
a single-tenant environment, but application information and destinations are aggregated across all
organizations.
FortiEDR 4.2 Study Guide
278
Multi-Tenancy
DO NOT REPRINT
© FORTINET
This slide shows a summary of all the features and roles in a multi-tenant environment. Admins in the Hoster
view can view and update global license and content data. They can also view and edit management console
users, distribution lists, syslog settings, audit trail, system events, and IP sets across all organizations. There
are also some features that can only be configured globally, and can only be viewed and configured in the
Hoster view. These include SMTP settings for email notifications, and scheduling periodic scans.
Admins can view and edit organizations in both the Hoster View and Organization view. In this view, all
administrative data—management console users, distribution lists, audit trail, and so on—is available for the
selected organization only. There are some settings that can be viewed and edited only within a specific
organization—component authentication (the Registration Password), automatic collector updates, and enduser notifications.
Local Admins have all the same views and permissions except for the Organizations panel—that is only
shown to hoster Admins.
FortiEDR 4.2 Study Guide
279
Multi-Tenancy
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
280
Multi-Tenancy
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 multi-tenancy works and how it can
benefit your organization.
FortiEDR 4.2 Study Guide
281
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
In this lesson, you will learn what the Fortinet Cloud Service is, why it is needed, and how it works.
FortiEDR 4.2 Study Guide
282
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in using the Fortinet Cloud Service, you will be able to handle events
management tasks.
FortiEDR 4.2 Study Guide
283
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Fortinet Cloud Service (FCS), is like a centralized brain that handles event management tasks. It evaluates
every event after it happens. The core makes the initial decision to block or allow and classifies the event,
then sends the data to FCS for further analysis. FCS verifies the classification and changes it if needed, then
carries out any assigned playbook actions for that classification. FCS is responsible for managing all
investigation actions, like putting a collector into isolation mode, and remediation actions, like deleting a
malicious file, in the playbooks.
The main advantage of FCS is that it improves the accuracy of event classification. In order to stop malware
from causing harm, you must decide in real time whether a process should be blocked or allowed. That’s what
the core does. FCS then conducts an in-depth analysis of the event, which would not be possible in real time,
and fine-tunes the classification. Ultimately, the goal is to classify all events as either malicious or safe, so
there is less need for time-consuming manual human analysis.
FortiEDR 4.2 Study Guide
284
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Now, you’ll take a look at how FCS fits in to the Fortinet infrastructure. As you saw in previous lessons, the
core receives event data from the collectors and sends back a verdict—allow or block. The core also sends
event data, including a preliminary classification, to the central manager through the aggregator, and on to
FCS. FCS maintains a constantly updated database of event and malware data, which it uses to conduct indepth event analysis and fine-tune the classification level assigned by the Core. FCS also handles
investigation and remediation tasks configured in playbooks. After remediating a malicious event, FCS
automatically marks it as handled. If FCS reclassifies an event as safe, it automatically creates an exception
so the same event will not be blocked if it occurs again. FCS sends all this information back to the central
manager, which displays it in the event viewer of the management console.
FortiEDR 4.2 Study Guide
285
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Now, you’ll take a closer look at how FCS works. First, it automatically evaluates each event based on its
extensive database of previous events. All that information is extremely useful in increasing Fortinet accuracy,
but it does take a few seconds to process. That’s why the initial classification happens at the core. The core
can evaluate an event and make a decision to block or allow it almost instantaneously. That’s important
because an attacker doesn’t need more than a few milliseconds to encrypt or steal data, so we need to be
able react in real time. After the core makes its decision, FCS fine-tunes the classification. The playbook
actions, are carried out based on the classification approved by FCS. For example, in the event you see on
the right, the Fortinet core classified the event as suspicious. If you look in the Triggered Rules section, you
can see that the event violated the Suspicious File Detected rule in the Execution Prevention policy, so
Fortinet blocked it, which you can see by the red icon next to the rule. Then FCS analyzed the event and
upgraded the classification to Malicious—it verified that the event was bad based on previous event data.
Based on this Malicious classification, FCS would have moved the affected collector into the High Security
collector Group, but the playbook was in simulation mode. You can tell by the gray Simulation label right
before the playbook action.
FortiEDR 4.2 Study Guide
286
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Take a look at the timeline of a typical event. The time the event first occurs is the starting point. If you look at
the event on the right side, you can see that the event happened on June 11th at 21:23 and 4 seconds. Within
milliseconds of the event, the core evaluated it, classified it, and assigned one of three actions—block, allow,
or log, depending on policy settings configured. In the example shown on this slide, you can see the History
section of the Classification Details pane for the event. The initial classification, at the bottom, was assigned
by the core – it classified the event as Inconclusive at 22:23 and 4 seconds—within one second of the initial
event. Next, FCS received the event data and carried out an additional evaluation, applying playbook actions
or exceptions as needed. Again, looking at the History, you can see that FCS revised the classification to
Likely Safe at 21:23 and 13 seconds. Still quick, but in this case about 9 seconds slower than the core. In this
example, you don’t see any playbook actions listed because there were no playbook actions selected for
Likely Safe events.
FortiEDR 4.2 Study Guide
287
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Fortinet uses two types of playbooks. The first is AIR. These are the playbooks you can see and configure on
the Security Settings tab of the management console. They are powered by FCS, but you can alter their
settings to suit your needs. AIR playbooks control event notifications—email, Syslog, or open ticket—and can
automatically isolate a device, move it to the High Security collector Group, and remediate it.
FCS playbooks can be enabled by Fortinet support on request. These playbooks use the Fortinet behind-thescenes knowledge to identify safe events and create automatic exceptions. You'll learn more about automatic
exceptions in this lesson.
FortiEDR 4.2 Study Guide
288
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
If you enable FCS playbooks, FCS can create exceptions automatically. When FCS analyzes an event, it may
find that an event that was initially blocked by the core was, in fact, safe. It can change the classification to
safe in these cases, but to make sure the event is not blocked again, it can also create an automatic
exception. You can see an example on the right side of this slide. This exception has a note saying it was
created by FCS, and you can see the date, time, and the reason the exception was applied.
Why should you enable automatic exceptions? There are advantages for both the end user and the system
administrators. End users can be more productive, because the safe process will not be blocked again. They
don’t have to call tech support to sort it out, it’s just automatically allowed. For the administrator, there’s less
work—your event viewer won’t be cluttered with safe events that you need to investigate and create
exceptions for. Note that if automatic exceptions are enabled, the system owner must follow up on all
automated exceptions. Fortinet is not liable for any exceptions created by FCS.
FortiEDR 4.2 Study Guide
289
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Isolation mode is a collector state used to help contain infections while they are being investigated and
remediated. AIR playbooks can be configured to place collectors automatically into Isolation mode when an
event is triggered. For example, you could configure a playbook so that all collectors that trigger an event
classified as malicious are automatically put into isolation mode.
Isolation mode is a state. It doesn’t affect the collector group assignment—a collector can be in isolation mode
and still remain in its usual collector group. However, collectors in isolation mode, are automatically assigned
to the Isolation Policy in Communication Control, rather than their group’s policy. The isolation policy is
built in, and by default, it blocks all applications from communicating. You can allow specific applications as
needed, such as helpdesk or security software. A best practice is to allow only applications you may need to
remotely remediate the device. You can manually put collectors into or out of Isolation mode on the Inventory
tab using the Isolate drop-down list. Collectors in isolation mode are marked with a red indicator icon.
FortiEDR 4.2 Study Guide
290
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
Fortinet aggregates events to make them easier for you to review. Raw data items are aggregated into a
single event based on the process, action attempted, and rules violated. For example, if a file called
driverupdate.exe makes multiple attempts to connect to the network, perhaps breaking the Non-standard
communication rule, each attempt would be aggregated into one event.
Events are then aggregated into alerts. You can aggregate events by device or by process. For example, if
you chose the Process view, all events involving the file driverupdate.exe would be aggregated into one alert.
If you are viewing events by process, you may notice that different events involving the same process can
have different classifications. The reason for this is that the classification is based not only on the process
itself, but also on what it was attempting to do. For example, take notepad.exe. It’s a very common text editing
application found on virtually all Windows machines, that is known to be safe. Normally, notepad.exe does not
generate any alerts, but if it were to violate an Fortinet rule while writing to disk—perhaps because of a
careless software revision—it would generate an alert. After reviewing the event, FCS would probably
reclassify that event as safe. You’d expect notepad.exe to write to disk, so this behavior doesn’t raise any red
flags. But say notepad.exe suddenly started a service, opened a port, and began listening. That’s not how a
text editor behaves, so FCS would probably reclassify this event as malicious. It’s the same signed executable
in both cases, but in the second event it’s behaving strangely and could have been hijacked by a malicious
process.
FortiEDR 4.2 Study Guide
291
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
When does FCS update an event? FCS evaluates each new event as it occurs. If the same event occurs
again—for example, if a process makes another attempt to connect to an IP address—FCS will re-evaluate
the event. If there is new information available at that time, FCS will update the existing event’s classification
as needed. In the example on the right side of this slide, there are 24 raw data items aggregated into the
highlighted event. Each time a new raw event occurred, FCS re-evaluated the event. On January 16, when
the initial event occurred, FCS classified it as Malicious. Five days later, a new raw event occurred, and
based on new data, FCS changed its classification to Safe. A day after that, the event occurred again, and
FCS reclassified it again, this time as Likely Safe. You can see these changes on the Classification Details
pane under History.
FCS does not evaluate old events unless they reoccur. The recurrence must be aggregated with the original
event in the same environment. This means that two companies with similar events may see different
classifications if their events occurred at different times.
Look at the timeline on the right side of this slide. Company A had two raw events events involving
GoogleUpdate.exe, on January 12 and January 18. Company B has three raw events involving the same
process and the same rule violation, with the last one occurring on January 22. FCS has acquired new data
throughout this time period, and revised its classification twice—once on January 21, and again on January
22. Company A had no new occurrences after FCS revised its classification. If each company reviews its
events at the end of the month, Company A will find the event classified as Malicious, as classified on
January 18, while Company B will find its event classified as Likely Safe, the current classification as of
January 22.
FortiEDR 4.2 Study Guide
292
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
How do you know if FCS is running in your environment? The quickest way to tell is by checking the
dashboard. At the bottom right corner of the dashboard, you’ll find the System Components health chart.
FCS is the fourth bar shown—if it’s green, then FCS is up and running.
If FCS playbooks are enabled in your environment you can also look for automatic exceptions in the
Exception Manager. FCS always leaves a comment in its exceptions, so if you search for the word cloud in
the comments, you’ll find any exceptions that FCS created.
FortiEDR 4.2 Study Guide
293
Fortinet Cloud Service
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
294
Fortinet Cloud Service
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 what the FCS is, why it is needed, and how it
works.
FortiEDR 4.2 Study Guide
295
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about advanced troubleshooting.
FortiEDR 4.2 Study Guide
296
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in advanced troubleshooting, you will be able to troubleshoot collector
upgrades, obtain collector logs to troubleshoot performance issues, including issues with third-party
applications, system hang, and system crash. You will also be able to create a memory dump, as well as
create a support case.
FortiEDR 4.2 Study Guide
297
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
This slide provides an overview of the troubleshooting process for collector upgrades. You'll learn more about
these steps later in this lesson. First, go on the management console and verify the settings. You don’t want to
go through the whole troubleshooting process only to locate that the collector group was set to the wrong
version.
Next, restart the device. Usually, upgrading the FortiEDR collector does not require a restart, but occasionally,
compatibility issues—usually with antivirus software—require a restart.
Third, locate the collector logs. You can do this on the local machine, or, if it’s connected, you can download
them through the management console. If you’re working with local logs, you can go through them to locate
the point where the failure occurred, or send them to Fortinet support. Logs obtained through the management
console are encrypted, so you must send them to Fortinet support for decryption and analysis.
Next, try updating the collector locally using the installer file.
Lastly, on rare occasions where the collector logs do not provide enough information, Fortinet support may
request that you run Process Monitor at the same time as the installation and return the logs. You don’t need
to do this unless specifically requested by support.
FortiEDR 4.2 Study Guide
298
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
Again, the first step in troubleshooting upgrades is verifying your settings on the console. First, you’ll need the
collector group assignment for the device you’re investigating. As you learned in earlier lessons, you can
locate that by clicking the Inventory tab and searching for the device name. In your search results, you’ll see
the collector group assigned to the device, and its version. Verify that the version number is what you were
expecting, and make a note of the collector group name. Remember, by default, you’ll see only Degraded
collectors, so make sure you click the blue Show all Collectors link.
Once you’ve got your Collector group assignment, you can check the assigned version on the Licensing
panel of the Administration tab. Click the Update Collectors button. You’ll see the Update Collector
Version dialog. locate the collector group you noted earlier and make sure it’s assigned to the correct
collector version.
Note that in a multi-tenant environment, Fortinet recommends performing device upgrades from the Hoster
View.
FortiEDR 4.2 Study Guide
299
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If the assigned collector group is what you were expecting, the next step is to restart the device. Wait a few
minutes after the restart finishes to make sure the Collector upgrade has time to complete, then return to the
Inventory tab and check the collector version again.
If you’re still seeing the old collector version, the next step is to retrieve the collector logs, either locally or
through the management console. You'll learn more about this process on the next slides. If you retrieved the
logs locally, you can search for the point where the upgrade failed before you send the logs to support. You’ll
locate a file called installer_<version number>, for example, installer_3.1.0.322.log. Press Control-F or
Command-F and search for value 3. That’s the numeral three, like it’s written on the slide. Now, look several
lines above the search result to locate the point where the upgrade failed.
If you downloaded the collector logs through the management console, they’re encrypted, so you won’t be
able to analyze them yourself. Fortinet support will be happy to decrypt and analyze them for you.
FortiEDR 4.2 Study Guide
300
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
Now, you'll learn about the process of retrieving collector logs. The easiest way to get the logs is through the
management console, which you can do if the device is currently connected to your network. Locate the
collector on the Inventory tab and select its checkbox. Then click on the Export drop-down list and select
Collector Logs. Save the logs locally. They will be downloaded into a password-protected zip file. The
collector files themselves are encrypted to prevent tampering, so you’ll need to send them to Fortinet support
for decryption and analysis.
FortiEDR 4.2 Study Guide
301
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
Collector logs are also available locally on each end user’s device. On Windows, you can locate them under
C:\Program Data\FortiEDR. You can also locate Windows Task Scheduler and Windows system logs on
your hard drive under Windows\Tasks, or if you’re still running Windows XP, you’ll locate it under
Documents and Settings\All Users\Application Data.
On a Mac, you can locate the logs in Library/FortiEDR/Logs/Collector, and
Library/FortiEDR/Logs/Driver.
On Linux version 2.6.x, logs are located in opt/FortiEDR/logs, or, on Linux version 2.7.x, you’ll locate them in
opt/FortiEDRCollector/logs.
FortiEDR 4.2 Study Guide
302
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If you’re still having trouble with upgrading your collector, try running the installer file locally on the end user’s
machine. To do this, you will need your organization’s registration password, which you can locate on the
Administration tab of the management console under Tools.
If Fortinet support needs additional information not included in the collector logs, they may request that you
run ProcMon, which is a free Sysinternals tool from Microsoft, alongside the install. This happens rarely, but if
it’s needed, just run ProcMon while performing the installation and save the ProcMon log to a PML file. Then
obtain the installer logs using the parameter /l*vx log.txt. and send these logs to Fortinet support.
FortiEDR 4.2 Study Guide
303
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If you’re troubleshooting performance issues on a device, begin by restarting. If that doesn’t help, disable the
collector in the management console. If the issue persists, upgrade the collector if there is a newer version
available.
If the performance issue continues, your next step depends on what type of problem you’re investigating.
You'll learn about each of these procedures in the next slides. If it’s a performance issue with a third-party
app, you’ll need to record the steps to reproduce the issue. For a system hang, create a manual crash dump,
then gather a full memory dump while the system is hanging. For a system crash, or blue screen of death
(BSoD), verify that the BSoD occurred, then gather a full memory dump while the system is hanging.
If you still need more information, try gathering collector logs while the device is running, using the procedures
you just went over. If you need help, file a ticket with Fortinet support.
FortiEDR 4.2 Study Guide
304
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
Now, you’ll go through these steps in a little more detail. If you’re having performance issues, the first thing to
try is disabling the collector, which you can do from the management console. If the problem persists when
the collector is disabled, the problem is not likely to be related to FortiEDR.
The next step is to check the collector version. You learned earlier about how to locate the current version of
the collector. Look for newer collector versions available in the Update Collectors dialog you saw earlier in
this lesson. Alternatively, you can open a support ticket with Fortinet support to learn the latest collector
version. If there are updates available, apply them to the affected collector and see if the performance
improves.
If you are still experiencing issues, replicate the issue and record the steps to reproduce it. You'll learn more
about this in the next slides.
FortiEDR 4.2 Study Guide
305
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If your performance issue involves a third-party application, you’ll want to start by checking for blocking
events. On the management console, click the Event Viewer tab and search for the executable file name of
the application you’re investigating. If you locate any blocking events, verify that they’re safe. It is possible that
an event involving a seemingly safe process is in fact malicious—for example, a malicious macro can run in a
legitimate copy of Microsoft Word, or a malicious program may be masquerading as a legitimate app. Once
you’ve verified that the event is safe, you can create an exception to allow the safe process to run.
If there are no blocking events and the application you’re investigating cannot connect to the network, check
the Communication Control policies. First, click the Communication Control tab and select Policies. Look
for the policy that has been applied to the user’s collector group. Then search the applications list for the
application. Highlight the application and check the Policies panel to make sure the user’s policy hasn’t been
set to deny communication from that application. Check individual versions too—sometimes an older version
is blocked for older versions with known vulnerabilities but allowed for newer, safer versions.
If you still haven’t found the source of the problem, retrieve the collector logs using the procedures that were
outlined earlier.
FortiEDR 4.2 Study Guide
306
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If you’re experiencing a system hang, start by creating a manual crash dump using the applicable instructions
from Microsoft or a third-party utility such as Bang.
Next, gather a full memory dump while the system is hanging. You'll learn the details of this process later in
this lesson. After you’ve finished, zip the memory dump and make note of the Sha256 to validate file integrity.
Lastly, retrieve the collector logs for the affected device. Again, to the procedures you learned earlier in this
lesson.
FortiEDR 4.2 Study Guide
307
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If you’re investigating a system crash, start by verifying that the BSoD occurred. You should locate a memory
dump and stop code in the memory.dmp file in the System folder. You can also check the Windows Event
Viewer Application Log. Search for kernel power to locate any records of a BSoD.
Next, create a full memory dump while the system is hanging. Zip the memory dump file and make a note of
the Sha256. You'll learn how to create a memory dump on the next slide.
Lastly, as with the previous procedures, retrieve the collector logs, either locally or through the management
console, as described earlier in this lesson.
FortiEDR 4.2 Study Guide
308
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
Now, take a closer look at the procedure for retrieving a memory dump. You’re going to focus on how to
capture a memory dump from a VMware Virtual Machine. This is a good option for system hang case. It also
doesn’t require interrupting the machine, so you can avoid forcing a crash or changing the Windows dump
parameters and restarting.
First, on the VMware vCenter, Workstation, or Fusion interface, take a snapshot. You can suspend the VM if
desired. Next, browse to the location where the VM is stored and locate the folder with the same name as the
VM. Inside that folder, locate the snapshot files. The filenames will start with the VM name -Snapshot. You
should a snapshot file (extension vmsn), or a suspension file (extension vmss), and also a non-monolithic
memory file (extension vmem). If there are multiple snapshots, the files will be numbered. Check the
timestamps to make sure you select the right version.
Once you have your snapshot files, download a copy of all available files for your snapshot and zip them. In
vCenter, you can do this by right-clicking on the files and choosing Download. If you’re not able to save the
files, copy them to the parent directory in the browser window and download them from there.
There are many more resources on memory dumps in the Advanced Level 1 Install and Performance
Troubleshooting Guide, which is available in your lesson materials.
FortiEDR 4.2 Study Guide
309
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
If you need help, Fortinet support can assist. Just open a support ticket on the Fortinet support site and
include a detailed description of the problem, when it occurred, and the steps to reproduce the problem. If the
problem is with a third-party application, also describe the performance issue and whether the entire device is
slow and, if so, how much slower is it running compared to normal operations. Also include the name, version,
and process name of the application or applications.
Attach a zipped copy of the collector logs. If applicable, also include a zipped recording from Windows Step
Recorder or memory dump and Sha256. Fortinet support will review the information and reply to you as soon
as possible.
FortiEDR 4.2 Study Guide
310
Advanced Troubleshooting
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
311
Advanced Troubleshooting
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 troubleshoot
collector upgrades, obtain collector logs to troubleshoot performance issues, including issues
with third-party applications, system hang, and system crash. You also learned how to create a
memory dump, as well as a support case.
FortiEDR 4.2 Study Guide
312
Endpoint Security 101
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about endpoint security and the history and fundamentals of malware.
FortiEDR 4.2 Study Guide
313
Endpoint Security 101
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in endpoint security, you’ll be able to understand malware and how trust is
exploited. You’ll also learn about boot processes, subsystem architecture, memory management, data
structures, and malware persistence techniques.
FortiEDR 4.2 Study Guide
314
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Start with the most basic question—what is malware? Malware is short for malicious software. It refers to any
software that is designed to harm a computer, server, or network. Viruses are a type of malware. They infect a
legitimate file on the user’s computer. When the user executes the infected file, they unknowingly execute the
virus. Viruses were the most common form of malware in the 1990s, so most early anti-malware programs
focused on that threat. That’s why anti-malware software became known as antivirus. The early, viruscentered approach to combatting malware was very heavily focused on signatures, which has become much
less practical and effective as malware has become more varied and more sophisticated.
FortiEDR 4.2 Study Guide
315
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Now, you'll learn about some of the ways that malware has changed over the years. The most obvious change is
the prevalence of malware. Back in the 1980s, the total number of attacks was in the hundreds. By 2000, there
were tens of millions of infections, and now there are hundreds of millions of attacks every year. There are also a lot
more malware variants circulating today. In 2010, AV-TEST registered 47 million malicious programs. Just nine
years later, they registered more than 976 million. That’s a massive quantity of data for antivirus to keep up with.
Distribution methods have also changed over time. Back in the 1980s, viruses were usually distributed by infected
floppy disks. Obviously, that limited their impact. Starting in the mid ‘90s, more and more people connected to the
internet and used email, and malware was able to spread easily to an ever-increasing number of computers without
any physical interaction between them.
The motive of cyber criminals has also changed quite a bit over time. Early on, malware was mainly intended to
create disruption. All the author hoped to gain was notoriety. However, by the mid-2000s, for-profit malware was
taking over. As more people went online, companies wanted to know what users were doing and get more people
viewing their advertisements, so adware and spyware became popular. Then, banking Trojans upped the stakes by
stealing financial data. Ransomware became another popular for-profit tool, with massive disruption as a side
effect. 2010 saw the first state-sponsored cyber warfare, which has become an increasingly effective weapon over
the last decade.
Motive has a big impact on sophistication. If you’re trying to create disruption for its own sake, there’s a limit on the
amount of time and money you’re likely to invest. Once there’s money to be made, that equation changes. Today,
malware is often created by teams of developers with significant funding, often from organized crime rings, so
they’re going to create more sophisticated malware than ever before. Once nation states start funding development,
you have even bigger budgets, even more resources, and even more advancements in the malware game.
FortiEDR 4.2 Study Guide
316
Endpoint Security 101
DO NOT REPRINT
© FORTINET
This slide shows some of the major developments in malware. The earliest malware was created as an
experiment by programmers and was never released to the public. In 1981, the Elk cloner became the first
malware to spread in to the wild, targeting Apple II. The Brain boot sector targeted IBM PCs for the first time in
1986.
As you learned earlier, early viruses were spread by infected floppy disks, so their scale was pretty limited. In
1988, the Morris worm became the first malware to spread over the early internet, crippling the system within
24 hours of its release. The Morris worm was also the first malware to lead to a criminal conviction under the
Computer Fraud and Abuse act of 1986.
In the 1990s, more and more people had personal computers, increasing the potential impact of malware. The
Michelangelo virus in 1992 generated a media storm, which raised public awareness of computer security
issues. A few years later, we started seeing macro viruses. Concept targeted Microsoft Word in 1995,
followed a year later by Laroux, which targeted Excel.
In the second half of the 1990s, people and were increasingly connecting to email and the Web, making it
easier to reach large numbers of people in a short amount of time. In 1999, Melissa became the first malware
distributed over email. It overloaded or shut down email servers at major corporations and government
agencies and slowed network traffic to a crawl. A year later, the ILOVEYOU virus combined email distribution
with social engineering, enticing people to open what appeared to be a text file called ILOVEYOU, sent by a
known contact.
In the 2000s, for-profit malware appeared and became increasingly dominant. The first banking Trojan, Zeus,
appeared in 2007, and has infected millions of machines and spawned generations of future malware.
FortiEDR 4.2 Study Guide
317
Endpoint Security 101
DO NOT REPRINT
© FORTINET
In 2008, Conficker—a very sophisticated and destructive worm—took disruptive malware in a new direction. It
infected major government agencies in France, the UK, Germany, and elsewhere, highlighting the
vulnerability of governments to cyber attack. It also demonstrated the possibility of creating a massive botnet
of hijacked computers, although the original authors never activated it.
Just two years later, the world’s first cyberweapon, Stuxnet, appeared. Stuxnet was the first malware to target
SCADA systems—specifically, the Iranian nuclear program. Because of its apparent political motives, its
sophistication, and the massive development costs, Stuxnet was generally attributed to an Israeli-US
collaboration, a suspicion confirmed by US officials in 2012. Stuxnet launched a cyber arms race around the
world. Two years later, Iran released Shamoon, targeting the energy sector in Saudi Arabia and other Gulf
states.
Meanwhile, malware for profit was still alive and well, and in 2013, ransomware really took off with
Cryptolocker, the first encrypting ransomware. It extorted about $3 million dollars before being shut down by
international law enforcement in 2014.
In 2017, the Shadow Brokers leaked several NSA exploits, putting nation-state level tools in the hands of the
public. WannaCry was the first malware to exploit these tools, and affected more than 200,000 machines in
more than 150 countries. It also impacted major corporations and agencies around the world, including
FedEx, DeutcheBank, Honda, and the Russian Interior Ministry. This was an unprecedented impact for a
single piece of malware. Wannacry has been attributed to a hacker group sponsored by the government of
North Korea, making it a hybrid of for-profit malware and cyberwarfare.
FortiEDR 4.2 Study Guide
318
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Why is malware such a popular attack method? There are several advantages to malware over more traditional crime.
First, there are lots of ways to exploit trust through malware. On the technical side, computers rely on the chain of trust to
prevent attacks. When you start up your computer, each startup element trusts the previous one. That’s a problem if
malware manages to hijack a startup element. For example, the operating system trusts BIOS and boot loaders, but
bootkits can hide down at the kernel level, compromising a computer before the operating system loads. Once your
operating system is running, it relies on the certificate chain to verify software, websites, identity, and so on. A certificate
is issued by a trusted certificate authority, like Verisign or Symantec—but malware authors can fake them or steal them
from legitimate programs.
Users’ trust can also be exploited. People generally trust known entities—emails that seem to be from someone they
know, or messages apparently generated by a known source, like the operating system or an antivirus program. Any
trust, programmatic or human, can be exploited.
A related advantage to malware is vulnerability. Technical vulnerabilities, including programming errors or deliberate
features with an unanticipated flaw, are constantly being discovered. Many of these vulnerabilities are only discovered
after malware authors have figured out how to exploit them. Even once a patch is issued, many people don’t install them.
Servers are particularly vulnerable here, because some cannot be shut down without creating a major disruption, and
most OS updates require a restart. Unpatched systems remain vulnerable to malware, and malicious actors are only too
happy to take advantage of that. Meanwhile, people leave themselves vulnerable with poor security habits. Most people
recycle passwords from one site to another, and many use easy-to-guess passwords. Many are also willing to risk their
security to get something for free, like torrents or freeware.
Lots of people leave themselves vulnerable in the real world—they leave their cars unlocked, leave their wallets in a back
pocket, leave their door key under the mat—but you generally have to be physically present to take advantage, and
you’re limited in how many people you can exploit at one time. That’s not the case with malware. If the malware is well
designed, you can watch it spread around the world from the comfort of your desk, your couch, or your local coffee shop.
In some cases, it continues to spread for years after its initial release, often using code tweaks to continue to evade
detection.
FortiEDR 4.2 Study Guide
319
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Now, you'll learn about how FortiEDR turns the cyber kill chain on its head. Most security software focuses on
the point of infiltration. It’s a little bit like a bouncer at a club—they’re trying to keep out anyone who might
cause trouble. Once someone get in, though, they’re not being watched as closely, so if they cause trouble—if
they start a fight, for example – they’re going to create some disruption before they get kicked out.
FortiEDR watches for malicious actions—attempts to steal or alter your data—then follows the chain from the
point of the consequences back to the source of the initial process.
This slide shows a process flow diagram from the FortiEDR management console. What you’re looking at is
effectively the chain of trust. In this example, Petya/Not Petya is trying to encrypt the device, but is blocked by
FortiEDR. If you look at the processes, they’re all legitimate Windows processes—explorer.exe launches
cmd.exe, which launches rundll32. Each trusts the previous process. If you look at the point of infection, you
can see rundll32 attempting to create several executables. Even though rundll32 is, in itself, a non-malicious
process, FortiEDR noticed that it was trying to create unmapped executables, so it blocked them before they
were able to encrypt the hard drive. If you delve into the event on the Forensics tab, you’ll see Petya/Not
Petya hiding in the command line. So FortiEDR works by monitoring for malicious activity up the chain, and
stopping the process flow before harm is inflicted.
FortiEDR 4.2 Study Guide
320
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Now, take a high-level look at computer architecture. A computer always uses various types of data storage,
but ultimately, all data passes through the CPU. The CPU trusts all these other components—peripheral bus,
registers, cache, memory controller—and these components trust the CPU. The operating system defines
how hardware is accessed and managed by applications, so if an attacker can gain control of the operating
system, they have full control. Because FortiEDR is based at a low level of the operating system, it can detect
attacks anywhere in the system.
FortiEDR 4.2 Study Guide
321
Endpoint Security 101
DO NOT REPRINT
© FORTINET
All major operating systems follow the same basic boot process. You can see the steps on this slide. The
process starts when the device is powered on, followed by some sort of BIOS boot. A boot loader is next, then
the operating system kernel loads. Load drivers load background services, and finally the user login. Each
item trusts the item to its left. There are multiple opportunities to infect this chain—from the lowest levels, like
a bootkit, to the user login at the end of the boot process. FortiEDR has detected attacks at every level in this
chain.
FortiEDR 4.2 Study Guide
322
Endpoint Security 101
DO NOT REPRINT
© FORTINET
This slide shows a comparison of Windows and Mac boot processes. The basic steps are the same. Very
broadly, they power on, there’s a self-test and the firmware launches, then the boot loader loads the operating
system kernel. The kernel then starts the initialization process, and finally the user logs in. Again, malware
can attack anywhere in this process, on both platforms. Macs, unfortunately, are not immune.
FortiEDR 4.2 Study Guide
323
Endpoint Security 101
DO NOT REPRINT
© FORTINET
This slide provides a much deeper look at an operating system architecture. Start with Windows. When you
dive a little bit deeper, it gets a lot more complex. You can see some of the common attack spots—local
security authority subsystem, SMSS service control manager, registry, and so on. When you think about how
all of these components trust each other, you begin to understand how easy it is to attack this sort of
distributed structure. The kernel level is in green at the bottom of the diagram. The line just above it is the
division between kernel mode and user mode. Privileged access to the operating system and the hardware
needs to cross from user to kernel mode. FortiEDR runs at the kernel level as a driver and is able to access
and monitor all of these areas.
FortiEDR 4.2 Study Guide
324
Endpoint Security 101
DO NOT REPRINT
© FORTINET
The diagram on this slide shows the macOS architecture. It’s very similar—just like Windows, it relies on trust.
The hardware is at the bottom of the diagram in green. Above that, is the kernel, or xnu, which contain nsthe
I/O kit and drivers. System utilities are in user mode above that, running as part of the core OS, then all of the
applications run at a higher level. You might notice that some of the applications, like JVM, go right down to
the system utility level, so they're very close to the kernel also. Just like Windows, there’s a lot of trust
between elements, so attackers have plenty of ways to get in.
FortiEDR 4.2 Study Guide
325
Endpoint Security 101
DO NOT REPRINT
© FORTINET
As you just saw, operating systems are very complex—there are lots of pieces, lots of trust between
elements, and lots of places a hacker can target. Now, you'll focus on one example: address space. When
you run a program, it uses virtual, or logical, address space. The CPU generates this address and maps it to a
corresponding physical address. This allows multiple applications to run at the same time without interfering
with each other. User-mode applications all use a virtual address space that is translated from the operating
system using a page table. As a security benefit, this achieves process isolation. The user, and user-level
applications, can’t directly access the physical address. In other words, a program that you run on the
Windows desktop should not be allowed to interfere with the operating system. If this system breaks down,
though, you can get collisions and violations of how space is managed, and malware can exploit that. Captain
Cook is one example of this. Certain antivirus software left kernel-level address space exposed to user-level
control. Remember, the kernel level has direct access to the operating system, but the user level does not.
With this vulnerability, any software that could write to that particular address space can run with kernel-level
privilege and control the entire operating system without any constraints.
FortiEDR 4.2 Study Guide
326
Endpoint Security 101
DO NOT REPRINT
© FORTINET
To better understand how Captain Hook works, take a closer look at how address space works. This is what
memory modules look like when they load. Modern operating systems are supposed to load each program in
a random place in memory each time it launches. That means you can’t predictably use an application’s
virtual address to reach a known place in memory—even if you know the virtual address, you don’t know
where it’s pointing. Even if you do manage to figure out the physical address on one machine, that won’t help
you access physical memory on a different machine, or even the same machine on a different day. In this
vulnerability, if you ran applications with certain antivirus software, they loaded in the same memory location
every single time, and it was predictable. Not only could the range of memory be used to run from user space
in kernel mode, but it was always the same location, so it made it very easy to predict.
FortiEDR 4.2 Study Guide
327
Endpoint Security 101
DO NOT REPRINT
© FORTINET
This slide shows how this attack works under the hood. When you activate Adobe Acrobat, it accesses the
Adobe process address space. It has read, write, and execute privileges for that space. Normally, this address
space is random, so if you quit Adobe Acrobat and then reopen it later, it’s accessing a different address
space. That means malware can’t reliably target a particular address. It's going to change, and if the malware
chooses the wrong address, the program will crash, which is annoying for the user, but the operating system
is protected.
The problem is that as of 2016, if an antivirus program like McAfee was installed, Acrobat always loaded at a
predictable address range. The attacker could use an infected PDF to execute code at a specific address
range and then effectively take over the entire system. If a user without an antivirus program like McAfee ran
the same PDF, the address space would be wrong, and it would crash Acrobat. If the user restarted Acrobat,
it would load in a different address space. That’s how memory is supposed to work.
FortiEDR 4.2 Study Guide
328
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Packing and obfuscation are common attack methods designed to disguise malicious files.
Packing disguises malware by combining it with a file the user wants. Users often take risks to get something
free—a pirated movie or game, for example. So the user voluntarily downloads the file, and the malware is
masked by the wanted content—in a zip file, for example. When they run it, they get malware along with the
expected content. Packers seen in the wild include Themida, Armadillo, UPX, and VMProtect.
Obfuscation disguises malware by adding superfluous code or altering code to make it harder to analyze.
Often, hackers use base64 to convert 8-bit code to ASCII, making it difficult to read. This slide shows an
example of an obfuscated command line exploiting trust in a Windows script to execute code. At the top, you
can see the obfuscated code. It’s hard to tell what it’s doing. Below that is the actual source code in which you
can see some red flags here that were hidden in the obfuscated code.
Packing and obfuscation are both used to hide malicious code. They both exploit the users’ trust in the type of
file being run or how many files they are running. It provides an opportunity to slip malicious activity behind the
trust of the user.
FortiEDR 4.2 Study Guide
329
Endpoint Security 101
DO NOT REPRINT
© FORTINET
This slide shows an example from a previous demonstration of packing a file. The goal is to run malware, but
you want to make the user launch it themselves. A payload file, in this case, a remote access Trojan installer,
and a desirable file being used as bait, in this case, Justin Bieber's Greatest Hits, were combined into a third
file. A user wants the music files, so they download and run a file called Justin Bieber's Greatest
Hits.exe, which very obviously in the foreground launches bieber-arc.exe, which creates a folder
containing MP3 files. On this slide, you can see the processes shown on the management console.
explorer.exe runs Justin Bieber's Greatest Hits.exe, which runs bieber-arc.exe, which
loads all the files on the desktop. This step violated the malicious file detected rule and was classified as
malicious, so FortiEDR would have stopped it immediately but, in this case, it was in simulation mode, which
you can tell from the gray oval. Since FortiEDR wasn’t in active protection mode, the process was allowed to
continue, and this is where the malware shows up. The user doesn't realize that while they’re getting their
mp3s, behind the scenes the same process, Justin Beiber’s Greatest Hits.exe, is using
svchost.exe to launch a listener for a remote access Trojan. You can see that this triggered the writeable
code rule and was classified as malicious. So, the user runs one file and gets what they want—in this case,
the mp3 files—but something harmful happens in the background.
FortiEDR 4.2 Study Guide
330
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Now, look at an example of an attack that exploits both user and operating system trust. This is the
IntelTruColor video driver update. It's a batch file disguised as a driver update. A user might think it’s safe
because it’s claiming to be a driver update from a trusted company. On the operating system side, it exploits
trust in a Windows script to install Cerber ransomware. The script may be encoded in Base64 to disguise its
malicious intent. On the left, you can see the command shell itself. It’s using a Windows scripting shell to
connect to a command and control server. This is a very obvious command line. In real life, it wouldn’t be this
obvious—the code would be obfuscated. On the right is the same text in Base64. It’s much harder to tell
what’s going on.
The script you see on this slide would be the second step of an attack. First, there would be a downloader,
and that downloader would load the payload.
FortiEDR 4.2 Study Guide
331
Endpoint Security 101
DO NOT REPRINT
© FORTINET
There are plenty of other attack vectors available. Each one of these methods exploits some sort of trust. For
many years, Microsoft Office trusted all Office documents, so it was easy to be infected by a macro. Now,
there are security measures built in to block macros, but users can override the software and allow the
macros if they think the file comes from someone they trust.
Windows help files have become a major vulnerability, as have scripting tools like Wscript, PowerShell, and
VBS. These are just a few of the attack vectors that exist—there are many, many more. Often, companies
think they’re protected because of specific security measures they’ve taken—“we've taught all of our users not
to run macros,” “we don’t use Windows Internet Explorer,” “we don't allow Windows scripting hosts,” “we don’t
allow Powershell,” and so on. Those are important measures, but they won’t protect you from every attack –
there’s always another attack vector. No one can anticipate them all, which is why FortiEDR focuses on
preventing harm—even if an attacker gets in, FortiEDR can stop them from stealing or encrypting data.
FortiEDR 4.2 Study Guide
332
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Once malware gets onto a device, it uses persistence techniques to stay there. The goal is to survive machine
reboot and removal attempts. Most software isn’t hard to stop—it’s not supposed to be. You can quit a
program whenever you want. If it won’t quit, you can force it to quit. If that doesn’t work, you can restart the
computer. Malware doesn’t make it that easy. There are lots of techniques to do this. This slide shows a few
of them.
A bootkit is malware that inserts itself into the master boot record. That means it loads before the operating
system, giving it access to virtually everything on the machine.
Another technique is DLL search order hijacking. This technique can be a bit confusing, so take a look at an
example. Imagine you click a “contact us” link on a website in Chrome, and it opens Outlook, your default mail
program, to send an email to the address in the link. To do this, the OS has to find Outlook. It always does this
in a specific order—in this case, it would look in the same folder as Chrome first, then in the System32 folder,
then the System folder, and so on. When it finds the file it’s looking for, it launches it. Malware can exploit this
by disguising itself as outlook.exe and putting itself in the Chrome folder or the System32 folder. If your
actual copy of Outlook is stored later in the search order—for example, in the System folder—Windows will
find and run the malware first.
Another common technique is modifying registry keys. The malware inserts itself into the registry key at a
specific place so that it is executed automatically under a specific set of circumstances—for example, when
Windows starts or when the user logs in.
Another method is shortcut hijacking. Say you have a shortcut to Firefox on your desktop. A shortcut can just
open the given application, or it can point to a specific website, like a local weather report, your webmail, or a
news site. Malware can alter your shortcut to download a payload from a malicious website.
FortiEDR 4.2 Study Guide
333
Endpoint Security 101
DO NOT REPRINT
© FORTINET
Now, look at an example of persistence. Poweliks is fileless malware that lives in the Windows registry. It
uses a base-64 encoded dll, and it exploits trust in PowerShell to hijack and run rundll32 during startup. At the
bottom of the slide, you can see the process flow as seen in the management console. The Windows logon,
and right away, FortiEDR detects an unmapped executable and process hollowing. In the example shown on
this slide, FortiEDR was in simulation mode, so you can see how the process plays out. In protection mode,
the malware would be stopped here. Next, it hijacks userinit, which launches Windows explorer, and so on. All
these processes are legitimate, but they’ve been hijacked by the malware. Farther down the process chain,
you'll see PowerShell using rundll32 to connect to command and control (C2). It sends data back to its C2
servers and receives instructions. On the right side are some of the functions that are extracted from
PowerShell.
FortiEDR 4.2 Study Guide
334
Endpoint Security 101
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
335
Endpoint Security 101
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 malware and how trust is exploited.
You’ll also learn about boot processes, subsystem architecture, memory management, data structures, and
malware persistence techniques .
FortiEDR 4.2 Study Guide
336
PowerShell and CScript
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the FortiEDR PowerShell and CScript module.
FortiEDR 4.2 Study Guide
337
PowerShell and CScript
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in PowerShell and CScript events, you will be able to triage PowerShell and
CScript events, and escalate an event, if you are unable to determine whether it’s malicious.
FortiEDR 4.2 Study Guide
338
PowerShell and CScript
DO NOT REPRINT
© FORTINET
PowerShell is a powerful scripting engine for Windows. It was initially released in 2006, and it has become
increasingly important ever since. It became an integral part of the Windows 7 operating system in 2009 and,
10 years later, it’s still built in to virtually all Windows machines. PowerShell offers deep operating system
integration, which gives it access to almost all Windows features and functions.
Because of this, most targeted and non-targeted malware campaigns today use some form of PowerShell
script communication or an encoded PowerShell command line to download and execute additional malware
components and/or run malicious code on a Windows system.
FortiEDR 4.2 Study Guide
339
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Now, you'll learn about triaging and classifying CScript and PowerShell events. Some events can easily be
classified. For example, legitimate PowerShell events rarely trigger rules such as unmapped executable,
process hollowing, or dynamic memory. If one of these rules has been triggered, the event is very likely
malicious. Other examples include encoded command lines or attempts to connect to unusual destinations.
Use caution when setting exceptions. Setting an exception on a PowerShell event warrants deliberate and
thorough consideration. You must set the exception to enable legitimate PowerShell communication without
allowing malware to communicate using PowerShell. If you're lost and you're unable to determine whether a
PowerShell event is safe, escalate the issue to the FortiEDR support team.
FortiEDR 4.2 Study Guide
340
PowerShell and CScript
DO NOT REPRINT
© FORTINET
There are a few common, obvious indications of malware to watch for. On the previous slide, you learned
about a few rules that are strong indicators of a malicious event. Another thing to look at is the command line.
Load the event on the Forensics tab and check the command line for indications of malicious activity. You'll
learn more about command lines later in this lesson.
If the event includes a destination IP address, check the reputation of that IP address using VirusTotal,
RiskIQ, or a similar tool. If the event includes an internal IP address, you need to confirm that that destination
is appropriate. You can use an internal IP set to limit any exceptions you create to allow only the appropriate
internal IP addresses. We’ll talk more about IP destinations on the next slide.
Lastly, look at the parent process. Does the parent process makes sense? Is there a legitimate reason that
the process would spawn PowerShell? Parent processes may also give you insight into the origin of an
infection. For example, if winword.exe was the parent process, the source is very likely an infected Word
file.
FortiEDR 4.2 Study Guide
341
PowerShell and CScript
DO NOT REPRINT
© FORTINET
When available, investigate the event's destination. Surprisingly, despite the availability of IP spoofing tools,
IP addresses are still a valuable clue in an investigation. Investigate any IP address involved in a PowerShell
event. In the event viewer, click to highlight the event and click Geo Location, if available, on the Advanced
Data pane. If you don’t see Geo Location, it is likely that the event did not attempt to contact any external
destinations. If there are external IP addresses shown, use VirusTotal, RiskIQ, urlscan.io, or urlinquiry.net to
scan the IP address for indications of malicious activity. For internal IP addresses, verify that the destination is
legitimate for the process that you're investigating.
FortiEDR 4.2 Study Guide
342
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Another way to evaluate an event is by retrieving and analyzing memory. You’ll need to do this if there's no
useful information in the command line. If the event is still in memory, you can remotely retrieve memory from
FortiEDR management console. Load the event onto the Forensics tab, and then select the process and
subprocess that triggered the event and click the Retrieve Memory button. Under Retrieve memory of
selected stack, select the Memory checkbox, and then click Retrieve.
If the memory is no longer available, you can export the collector logs for the affected devices and extract
them using the password enCrypted. As you learned earlier, collector logs are encrypted. FortiEDR support
can decrypt them for you.
Be aware that analyzing artifacts, such as PE files retrieved from memory, requires advanced technical and
forensic analysis skill sets. If you are not comfortable analyzing memory artifacts, the FortiEDR forensics team
can assist in investigating any artifacts retrieved from memory. Work through your support team to create a
forensics escalation case.
FortiEDR 4.2 Study Guide
343
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Take a look at some examples of PowerShell events, starting with safe events. The example on this slide
shows an event involving PowerShell and VBScript. The command line suggests that a VBScript spawned
powershell.exe to run a PowerShell script. The PowerShell command appears to change each time it's
executed. The VBScript name remains constant. You’ve investigated the event and determined that it is safe,
so the next step is to create an exception.
Use extra care when applying exceptions to powershell.exe or cscript.exe. Both are commonly used
by malware authors as well as legitimate processes, and you don’t want to create an exception that will allow
malware to execute. Avoid applying broad exceptions whenever possible. The more specific your exception,
the safer your network will be.
In the example shown on this slide, the PowerShell command changes, so you need to apply that exception to
CScript. Use the Only when executed with option to limit the exception to allow CScript only when used with
the safe script.
FortiEDR 4.2 Study Guide
344
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Next, take a look at a PowerShell event involving randomized script names. In the scenario shown on this
slide, the PowerShell process was spawned by a third-party application. The command line, which you can
see at the upper right, suggests that PowerShell attempted to run a script. Similar events in the event viewer
suggest that the script name is randomized each time the process is launched but always uses a consistent
extension, .tmp.ps1. You’ve analyzed the events and determined that they are safe.
How can you apply a safe exception? Since all the scripts use the same extension, you can limit the exception
to allow PowerShell only when executing script names ending .tmp.ps1. Use a wildcard to represent the
randomized portion of the file names: *.temp.ps1.
FortiEDR 4.2 Study Guide
345
PowerShell and CScript
DO NOT REPRINT
© FORTINET
The example shown on this slide is an attempted connection with PowerShell ISE. A legitimate PowerShell
ISE attempted to connect to a remote IP address. No command line information is available, but the process
was found to be safe.
You’ll need to create an exception for powershell_ise.exe. We’ll limit the allowed destinations to narrow
the exception. If the event attempted to connect to internal destinations, apply the exception to the built-in
internal IP set. For an event that attempted to connect to public IPs, verify each IP address, and allow only
addresses involved in the event, or create an IP set and limit the destination to that set.
FortiEDR 4.2 Study Guide
346
PowerShell and CScript
DO NOT REPRINT
© FORTINET
The example on this slide shows a safe process involving PowerShell attempting to connect to an IP address.
The PowerShell process was spawned by cmd.exe. The PowerShell process then attempted to connect to
an external IP address. There's no command line available, but the process has been found to be safe. You
will set the exception on cmd.exe, which is much less often targeted by malware attacks, and limit the
destination to specific IP sets, as illustrated in the previous example.
FortiEDR 4.2 Study Guide
347
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Now, you will review the best practices for creating exceptions. First, whenever possible, apply exceptions to
a third-party process rather than PowerShell or CScript. Both PowerShell and CScript are frequently used by
malware authors, so using a less common process makes for a much safer exception.
If you need to apply an exception to a common Windows process like PowerShell or CScript, use the Only
when executed with option, if available, to limit the exception to a particular script.
Lastly, limit the destinations included in the exception. Use the IP sets feature to limit exceptions to a
particular set of safe destinations. There's a significantly reduced chance of allowing a connection to a
malicious IP address. Create customized IP sets as needed for cloud services, database servers, credit card
servers, and so on.
FortiEDR 4.2 Study Guide
348
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Now, you'll look at some malicious events. In the example shown on this slide, the PowerShell process was
spawned at the end of a series of safe processes. The chain of events, which you can see on the right,
suggests that a malicious Word document was sent by email. The command line script, on the lower right,
indicates that the script attempts to download a payload from one of several malicious websites. The event
has been analyzed and has been found to be malicious. Your next step would be to remediate the event.
You'll learn about how to remediate a malicious PowerShell event in this lesson.
FortiEDR 4.2 Study Guide
349
PowerShell and CScript
DO NOT REPRINT
© FORTINET
The example on this slide shows a PowerShell script that includes an obfuscated command line script. In this
scenario,the PowerShell process is spawned by cmd.exe. The script then attempted to communicate with a
public IP address. The command line script is encoded. The first step is to decode the script. Copy the
command line to a text file and use the Windows Certutil utility to convert the encoded blob into a readable
string. Save the readable script to a separate file. You can see an example on the right. The upper blue box is
the encoded file, and below that is the exposed command. If you analyze the command line, you’ll see clear
evidence of malware.
FortiEDR 4.2 Study Guide
350
PowerShell and CScript
DO NOT REPRINT
© FORTINET
Once you’ve determined that a PowerShell is malicious, you’ll need to take steps to remediate it. The first step
is to find and delete the malicious file. When possible, you can also block the domains associated with the
URLs in the script. You could also query the firewall logs to find out which other users may have received the
file. If the event was not blocked, check any events following the initial PowerShell event, that involve the
unmapped executable, injected process, process hollowing, or malicious file detected rules. Check each hash
in VirusTotal. If you're certain the device is infected, consider reimaging the device and resetting any
associated user passwords.
FortiEDR 4.2 Study Guide
351
PowerShell and CScript
DO NOT REPRINT
© FORTINET
There are quite a few additional scenarios involving PowerShell and CScript. The malicious PowerShell
scenarios described here, are only a small subset of the PowerShell attacks that exist today. These examples
are intended to illustrate how to efficiently and effectively analyze a PowerShell event that seems malicious or
suspicious. The safe processes you saw are also a small sample, intended to illustrate different methods of
creating a safe exception.
If you're still unsure about the legitimacy of the payload, please work through your support team to create an
escalation case for the FortiEDR forensics team. The FortiEDR forensics team can assist you in investigating
the threat.
FortiEDR 4.2 Study Guide
352
PowerShell and CScript
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
353
PowerShell and CScript
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 triage PowerShell and CScript events,
and escalate an event if you are unable to determine whether it’s malicious.
FortiEDR 4.2 Study Guide
354
Alert Analysis 401
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about alert analysis, alert management analysis, and best practices.
FortiEDR 4.2 Study Guide
355
Alert Analysis 401
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in alert analysis, you’ll understand about alert classification, the most effective
workflow and best practices for alert analysis, and how to create safe and effective exceptions.
FortiEDR 4.2 Study Guide
356
Alert Analysis 401
DO NOT REPRINT
© FORTINET
The goal of alert analysis, simply stated, is to process received alerts by evaluating and analyzing unknown
alerts and sorting them into categories. Sorting alerts is like sorting recycling: you use four containers, or
categories, and each event must go into the right container.
• The first category is block. These are files that you know are malicious and should continue to block. You’ll
also need to remediate any systems that were infected.
• The second category is evaluate. These are processes that you’re not certain about, so you’ll need to
perform additional analysis before deciding how to handle them.
• The third category is allow. These are processes you know are safe, and you’ll need to create exceptions
to allow them to run in the future.
• The last category is archive. If you are unable to determine whether an event is malicious, archive it and
follow up if and when it reoccurs.
Here are some tips for effective alert analysis. If you look at the Triggered Rules section of an event,
FortiEDR recommends next actions. This is a great starting point for your analysis. FortiEDR classifications
also offer a quick reference to help you prioritize events and choose the appropriate next steps. FortiEDR
classifies events automatically, but you can change the classification if needed, based on your analysis. Note
that the most recent classification always takes precedence, whether it was assigned by a user, the core, or
Fortinet Cloud Services.
Do not submit samples to VirusTotal. Anyone with a membership can download the sample once it is
uploaded. You probably don’t own the executable you’re investigating, and it could contain sensitive
information if legitimate. In addition, submitting a sample can tip off the malware authors. Malware authors
often watch VirusTotal to see if they’ve been detected. If so, they will alter their methods to make it harder for
you to spot an attack.
FortiEDR 4.2 Study Guide
357
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Take a look at how classifications fit into the workflow. As you’ve learned, FortiEDR provides you with a
classification of each event. You can use that classification to quickly identify which category each event falls
into so you can easily prioritize events and plan your workflow.
Malicious and suspicious events should be in the first bucket, block. Likely safe and safe events should be in
the verify and allow category. Inconclusive and PUPs fall into the evaluate bucket. Based on your evaluation,
you can choose the appropriate next step—remediate and continue to block, create an exception, or, if you
aren’t able to determine whether the event is safe, archive for it and review it if it reoccurs. There are a few
other situations where you should archive an event, which you'll learn about later in this lesson.
FortiEDR 4.2 Study Guide
358
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Now, you will briefly review how playbooks work. You can configure playbooks to carry out specified steps
after an event based on its classification. For example, after a malicious event, a playbook could send
notifications, put a collector into Isolation mode, and terminate a malicious process. Automating these tasks
can greatly reduce workflow and the total cost of ownership.
Like security policies, playbooks can be in simulation or protection mode. In simulation mode, Playbooks will
send notifications as configured, but no further action is taken. In protection mode, all configured actions will
be carried out. In the Event Viewer tab, you can check the History section of the Classification Details
panel to see what actions were taken, or, if the playbook was in simulation mode, what actions would have
been taken if the policy had been in protection mode.
FortiEDR 4.2 Study Guide
359
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Now, review how blocking happens. Remember, the playbook does not decide which events should be
blocked or allowed. That decision is based on security policies.
Each of our security policies—execution prevention, exfiltration prevention, ransomware prevention, and
device control—is made up of a set of rules. Each event you see in the event viewer has violated one or more
of these rules. Rules can be enabled or disabled. Every rule is also assigned an action—events that violate
the rule can be either logged or blocked. You can change the action for a rule if needed.
How FortiEDR responds to an event depends on both the policy mode and how the rule is configured. For
example, if a rule is enabled and set to Block, but the policy is in simulation mode, an event that violated the
rule will be recorded in the console as Simulated block but will be allowed to continue. If the policy is in
protection mode and the violated rule is enabled and set to Log, the event will be logged in the event viewer
but allowed to continue. You’ll look at policy modes, rule states, and assigned actions on the next slide.
FortiEDR 4.2 Study Guide
360
Alert Analysis 401
DO NOT REPRINT
© FORTINET
As you just saw, there are three settings affecting the behavior of each rule. First, the policy can be in
simulation or protection mode. Second, the rule can be set to Block or Log. Third, the rule may be enabled or
disabled. The combination of these settings determines what FortiEDR does when an event occurs.
• If a policy is in simulation mode, nothing is blocked, even if the event violated a rule set to Block.
• If the policy is set to protection mode and an event violates a rule that is set to Block, that event will
immediately be blocked.
• If an event violated a rule set to Log, FortiEDR will record the details in the event viewer, but no action will
be taken, even if the policy is in protection mode.
• If a rule is disabled, events that violate the rule are completely ignored regardless of the policy mode—they
are not blocked, and there is also no record of them in the console. For this reason, if you don’t want to
enforce a rule, FortiEDR recommends setting a rule to Log rather than disabling it.
FortiEDR 4.2 Study Guide
361
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Take a closer look at how classification and playbooks work. Again, this should be familiar from earlier
lessons, but it’s useful to keep in mind when you’re analyzing events.
Within milliseconds of detecting potentially malicious activity, the FortiEDR core, makes a decision—either
block the action or allow it to continue. It also assigns the event an initial classification, which is displayed in
the Classification Details pane of the event viewer.
Next, the Fortinet Cloud Service (FCS), will further evaluate the event and reclassify it if necessary. Based on
the classification—either from the core or, if revised, from FCS—FCS will carry out any assigned playbook
actions.
In this example, the event has initially come in at 3:47 and 55 seconds and was categorized as suspicious and
blocked. Then at 3:48 and 10 seconds, FCS compared the event to its database of previous known events
and reclassified it as Malicious. Based on the new Malicious classification, it would have moved the affected
device to the High Security Collector Group, but the playbook was in simulation mode. In simulation mode,
FortiEDR records what actions would have been taken, but no changes are made to the device settings or
files.
Please note that if you manually change an event’s classification, no playbook actions will be carried out
based on your revised classification.
FortiEDR 4.2 Study Guide
362
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Now you’ll review event archiving. Archived events are not deleted, but are hidden from the default events list
view. You can view archived events by changing the red drop-down filter to Archived. Archived events are
marked with a gray box icon. If an archived event recurs, a new event is created. The new event will not be
marked as archived, so you’ll see it in your default events list view.
You can also archive events that are no longer relevant. For example, an event that has not recurred in
several months is no longer active, and may be more difficult to investigate. You can archive these events and
then revisit them if they reoccur later on.
FortiEDR 4.2 Study Guide
363
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Marking an event as handled indicates that you have dealt with the event and no further action is needed. If
an event that has been marked as handled recurs, that handled event become unhandled once again.
Handled events are hidden from the events list by default. If you need to see events that have been marked
as handled, switch the red status filter to All. Handled events are shown with a light flag.
You can mark an event as handled if you have created an exception and are confident that it covers all
variations of the event, either because you’ve waited a period of time and no variations have occurred, or
because you’re confident that the exception was broad enough to cover all variations.
You can also mark an event as handled if you have remediated an infection and are confident that the event
won’t recur. You’ll learn more about handling and archiving later in this lesson.
FortiEDR 4.2 Study Guide
364
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Remember that you can aggregate events by device or process. During the tuning process, best practice
dictates viewing events aggregated by process, not by device. In a large installation, there may be hundreds
of thousands of systems, but only a handful of processes. If you sort by process and evaluate one potentially
malicious process at a time, you can address and resolve a large number of events at once. For example, say
you have proprietary software installed on every device, and it behaves in an unusual way, but you know it’s
safe. If you sort by process, all events involving that software will be grouped together, so you can address
them and check for variants all at once. If you sort by device, every device that runs the process will be listed
as a separate alert, so you’ll have a lot more to wade through. Sorting by process also allows you to quickly
see whether an exception you’ve created addresses all variations of the process by checking the exception
icon. If you see a pencil in the upper-right corner of the icon, the event is covered by an existing exception.
FortiEDR 4.2 Study Guide
365
Alert Analysis 401
DO NOT REPRINT
© FORTINET
This slide provides a high-level overview of how Fortinet recommends processing events. As you go through
the details of each part of this process, you'll continue to refer back to this high-level process.
The first step is to prioritize events. Prioritize recent events, events that were blocked, events with many raw
data Items, and events involving critical applications.
Next, investigate each event to determine whether it is safe or malicious. Look for red flags, check any IP
destinations involved in the event, and evaluate the event on the Forensics module.
Based on your investigation, you’ll decide whether the device is infected and should be remediated, or if the
event is safe and you need to create an exception.
Lastly, you’ll handle or archive the event as appropriate.
FortiEDR 4.2 Study Guide
366
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Notice the flow chart at the top of this slide—you’re going to work from left to right through each stage you
learned about on the previous slide, starting with prioritizing events.
The first step is to choose a timeframe. If you have a backlog of events to process, don’t try to handle all of the
events at once. Choose a reasonable time frame to focus on—for example, two months—then archive any
events that occur outside this timeframe. There's a very high chance that these older events are irrelevant. If
they're still relevant, you'll see them again and be able to tune them. Use the advanced search feature to
narrow your list to events that were last seen before your chosen time frame. Verify your results, then select
the event checkboxes and click the Archive button. If you don’t have a large backlog, you can skip the
archiving step.
Next, sort your events by Last Updated so the most recent and relevant events are on the top. These are the
events that are still receiving updates, and should be your first priority.
FortiEDR 4.2 Study Guide
367
Alert Analysis 401
DO NOT REPRINT
© FORTINET
The next step in prioritizing events is to find high-impact events. Blocked events are generally the most
serious. To find them, use the advanced search feature to search for an Event Action of Block. If you have
collectors that are still in simulation mode, you’ll also need to search for Simulation Block.
Next, look for events with a large number of raw data items. Events with a large number of raw data items
could represent a network-wide issue or widespread attack.
Third, search for events involving common critical applications. Critical applications being blocked may inhibit
productivity. Examples are Microsoft Office, mail applications, web browsers, Java, and so on. Please use
extreme caution when creating exceptions for common critical applications. Many common critical
applications can be hijacked and used as a pass-through by malware. For example, a downloaded Microsoft
Word file can be used to launch malicious macros. Creating an exception that allows any program that is
launched by Microsoft Word to be allowed would open up far too much of a risk, and is an inappropriate
exception. You’ll learn more about creating exceptions in this lesson.
FortiEDR 4.2 Study Guide
368
Alert Analysis 401
DO NOT REPRINT
© FORTINET
After you have prioritized your events, you can begin the investigation phase. The first step is to look for red
flags. Now you will examine three red flags that may indicate malware is present:
First, look for an unusual parent process. For example, Microsoft Word is not normally the parent process of a
system process such as cmd.exe, the command shell, PowerShell, or a service host. This can be a very
good indication of a malicious macro.
Next, check for unusual file paths. Files that are run from a temp folder rather than the user's documents or
downloads folder may indicate that the user did not intentionally save and run the file from that location. For
example, a process running from a user’s appdata or a temp folder would very likely be malware.
Lastly, some rules are considered high fidelity. These rules are rarely violated by legitimate programs, so if a
process violates them, it is very likely to be malicious. The high fidelity rules are: fake critical program, invalid
checksum, partially mapped file, tampered executable, process hollowing, injected process, or unmapped
executable. Please note these rules are considered as part of the event classification process behind the
scenes by FortiEDR, so processes that violate them should already be blocked and classified as malicious.
Still, it’s important to understand how to use them as part of a manual evaluation process.
FortiEDR 4.2 Study Guide
369
Alert Analysis 401
DO NOT REPRINT
© FORTINET
The next step in investigating events is to verify destinations. You learned about this process in the previous
lesson. Verify that the destination system and country makes sense for the process in question, then use
VirusTotal or another tool to scan the address for any indications of malicious activity. Remember, if the
address is safe, the process could still be malware using an IP spoofing tool, but if the IP is associated with
threat actors, you can be confident that the process is malicious.
FortiEDR 4.2 Study Guide
370
Alert Analysis 401
DO NOT REPRINT
© FORTINET
When you load an event on the Forensics tab, you’ll see a lot of useful details that can help you investigate
events. Now, you’ll briefly review how to load an event onto the Forensics tab. First, find the event or events
in the event viewer, select the checkbox for each event that you want to see, and then click the Forensics
button to load the selected events onto the Forensics tab. Remember, you need to click the Forensics
button. If you click on the Forensics tab at the top of the screen, you will see the Forensics tab, but your
events will not be loaded.
If you want to load more events, return to the event viewer and use the same process. If you see a fingerprint
next to an event in the event viewer, it's already been loaded on the Forensics.
Remember to periodically clear events by clicking the X on the event’s tab or selecting the Clear All button.
FortiEDR 4.2 Study Guide
371
Alert Analysis 401
DO NOT REPRINT
© FORTINET
When you first load an event on the Forensics tab, you’ll see the flow analyzer view. In the flow analyzer
view, evaluate each process from left to right. One or more of the initial processes in the chain should be
familiar. In the example shown, the first process is winlogon.exe, which launches userinit.exe, which
are both part of the user login process. userinit.exe then launches explorer.exe. These are all wellknown and safe Windows processes. The first process that is not really a legitimate or well-known process is
installer.exe on the right. This is where you should start your investigation. Check for a file signature. Is
the provider legitimate? Is the signature valid? Check the hash in VirusTotal to see how other anti-malware
programs handled it. In some cases, you can search for the filename online to see if any red flags appear. In
the example shown on this slide, the filename is too generic for an internet search.
FortiEDR 4.2 Study Guide
372
Alert Analysis 401
DO NOT REPRINT
© FORTINET
As you move through each process, pay special attention the triggering process or processes. In the process
flow view, each process is marked with the names of the rules it violated. In the stacks view, each process
that violated a rule is marked with a red dot. Within a process, you can also find the sub-process or subprocesses that violated the rule by looking for red dots. Click on the sub-process to see the rule that was
violated. You can investigate the sub-process hash in VirusTotal as well as the main process hash.
FortiEDR 4.2 Study Guide
373
Alert Analysis 401
DO NOT REPRINT
© FORTINET
As we mentioned earlier, FortiEDR comes out of the box with four security policies: Execution Prevention,
Exfiltration Prevention, Ransomware Protection, and Device Control. Each of those policies is made up of a
set of rules, and each rule falls into one of two categories: static or dynamic. The type of rule violated affects
how you should investigate the event.
Static rules are related to files. For example: malicious file detected, fake critical program, and suspicious
packer. To investigate an event that violated a static rule, retrieve the malicious file, if possible, and test it in a
sandbox environment.
Dynamic rules are related to memory. For example: process hollowing, dynamic code, and injected process.
To investigate an event that violated a dynamic rule, you’ll need the memory context. You'll take a detailed
look at how to investigate an event that violated a dynamic rule next.
FortiEDR 4.2 Study Guide
374
Alert Analysis 401
DO NOT REPRINT
© FORTINET
For dynamic rule violations, you can retrieve the disk memory of the event memory. If the device is
connected, you can do this through the management console. If the event is still in memory, you can retrieve
the memory directly using the memory retrieval feature. First, load the event on the Forensics tab and find
the red dot that displays where the violation occurred. Select the checkbox next to the triggering sub-process
or sub-processes and click the Retrieve button. You can collect samples either directly from memory or from
disk. You can also choose to retrieve memory from a specific address range or the entire process memory.
The memory, if available, will be downloaded into a zip file. Unzip the file using the password enCrypted
with a capital C.
Memory is volatile—sometimes it will have been overwritten by the launch of another process or a reboot of
the system before the investigation begins. However, when an event violates a dynamic rule, the FortiEDR
collector automatically creates a memory dump. You can retrieve this memory dump from the collector logs.
Click on the Inventory tab and select Collectors. Select the checkbox next to the collector, and then click the
Export menu and select Collector Logs. The logs will be encrypted and saved in a zip file. Send the files to
FortiEDR support for decryption.
FortiEDR 4.2 Study Guide
375
Alert Analysis 401
DO NOT REPRINT
© FORTINET
If you’ve analyzed an event and verified that it was malicious, the next step is to remediate the infection. You
can start by applying extra protection to the affected collector or collectors. As you learned in earlier lessons,
isolation mode disables communication from virtually all applications by default, and the High Security
Collector Group is a built-in group intended to be kept in protection mode with strict policy settings applied.
Depending on how you’ve configured your playbook, infected collectors may already be isolated and/or
moved to the High Security Collector Group. If not, you can do this manually. On the Inventory tab, select the
checkbox for each collector. Click the Move to Group button and assign the collector to the High Security
Collector Group. To place a collector in isolation mode, select the checkbox beside it, click the Isolate dropdown list, and then select Isolate. Isolated collectors appear with a red isolated icon next to the collector
name. Collectors should remain isolated until the device has been remediated or no new malicious events
have occurred within the last week.
Remember that FortiEDR will continue to protect your system even if you choose not to use isolation mode or
the High Security Collector Group. They are available as an added security measure to protect and contain
infected collectors.
FortiEDR 4.2 Study Guide
376
Alert Analysis 401
DO NOT REPRINT
© FORTINET
After you’ve isolated and protected your infected devices, remediate the infection. There are several
remediation options available on the Forensics tab. Bear in mind that the device must be online to enable
remote remediation. Again, depending on your playbook configuration, infected systems may have been
automatically remediated. If not, you can remediate manually. Load the event on the Forensics tab. Find the
process or processes that violated rules (marked with red dots) and select the checkboxes next to them. Then
click the Remediate button. There are several options available:
• Terminate process ends the current process associated with the selected file, if it’s still running.
• Remove selected executable file deletes the selected files from the device.
• Remove file at path deletes the file at a location that you specify on the device.
• Handle persistent data (registry) removes or repairs registry keys that may have been altered by the
selected process.
FortiEDR 4.2 Study Guide
377
Alert Analysis 401
DO NOT REPRINT
© FORTINET
If you investigated an event and found that it was safe, the next step is to create an exception. An exception
tells FortiEDR that a rule should not be triggered if the exact conditions in the exception are met. In the
example exception shown on this slide, for all groups, if the same signed executable runs from the same path,
it will not trigger a PUP violation if it communicates with an internal destination.
To set an exception, click the exception icon next to the event in the event viewer to open the Exception
Creation dialog box. Define the parameters of the exception, add comments about why the exception was
created, and then click Save. You'll take an in-depth look at exception parameters in the next few slides.
FortiEDR 4.2 Study Guide
378
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Here are some guidelines for setting safe exceptions:
When setting an exception, apply the exception to all groups unless you have a specific reason not to.
Exceptions are applied on a per group basis, so if a collector is moved to another group, it will lose all of its
exceptions unless the exceptions are applied to all groups. This can cause problems for you and the end user.
When possible, limit the destinations allowed in the exception. For events that violated the File Encryptor or
Communicating Macro rules, apply the exception to all internal destinations if the current destinations are
internal. For events involving a cloud service, configure an IP set including the relevant IP range, and limit the
destinations to that IP set. You’ll review how to configure IP sets on the next slide.
FortiEDR 4.2 Study Guide
379
Alert Analysis 401
DO NOT REPRINT
© FORTINET
You can configure IP sets on the Administration tab of the management console under IP Sets. Click Define
new IP set, then add any IP addresses needed—for example, a range of IP addresses associated with
Google Cloud. You can add IP addresses individually, by range, or by subnet. You can also exclude specific
IP addresses from an allowed range. FortiEDR comes preconfigured with an internal destinations IP set. You
cannot edit the built-in IP addresses, but you can add addresses to the Included IPs list or use the Excluded
IPs list to exclude an address on the list. Once your IP sets are configured, you can use them to limit the
destinations covered by your exceptions.
FortiEDR 4.2 Study Guide
380
Alert Analysis 401
DO NOT REPRINT
© FORTINET
Now take a look at some advanced guidelines. The Advanced section at the bottom of the Exception
Creation window offers additional options to make a more secure exception.
First, you can choose which process the exception applies to. Avoid applying broad exceptions to a common
system process or dll. For example, applying an exception to all events involving Java will prevent alerts on
any process that attempts to use Java in the future. Whenever possible, apply the exception to a more
specific sub-process. You also have the option to apply the exception to the main process, but only when
executed with a specific sub-process. The example on this slide shows an exception to Java applied, but only
when executed with the sub-process Server_Ready1.jar. If a malicious process tries to use Java in the
future, it will be still be blocked.
You can also specify whether the selected process can run from anywhere on the hard drive, or only from a
specific path. To maximize protection, apply the exception to the specific file path rather than allowing the
process to execute from any location on the hard drive. You can substitute wild cards for specific portions of
the file path to allow common variations, such as version numbers or usernames.
FortiEDR 4.2 Study Guide
381
Alert Analysis 401
DO NOT REPRINT
© FORTINET
The last step of alert analysis is archiving or marking an event as handled. You learned about this earlier in
the lesson, but you’ll go over some of the specifics here. When should you archive an event? Archive a safe
event after creating a specific exception. As you learned earlier, if a variation of the event occurs that is not
covered by the exception, a new event will be created and shown in the default event list view. You can also
archive an event if you're unable to determine whether it was malicious. If the event recurs, a new event will
be created and you can try to obtain more data.
When should you mark an event as handled? Mark a malicious event as handled when you've verified the
malware, finished all necessary remediation, and confirmed that the malicious event will not recur. Mark a
safe event as handled when you're certain that the event will not be blocked again by FortiEDR.
When you click the Handle Event button, the Event Handling dialog box opens for the checked event. Based
on your analysis, you can change the event’s classification if needed. A best practice is to leave a detailed
note explaining how you handled the event. Click Save as Handled to change the event’s status. If you want
to change an event’s classification or leave a comment without changing its status, click the Save button.
FortiEDR 4.2 Study Guide
382
Alert Analysis 401
DO NOT REPRINT
© FORTINET
FortiEDR 4.2 Study Guide
383
Alert Analysis 401
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 alert classification, the most effective
workflow and best practices for alert analysis, and how to create safe and effective exceptions.
FortiEDR 4.2 Study Guide
384
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© 2020 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.