FortiOS® 6.4
Security Target
Evaluation Assurance Level (EAL): EAL4+
Doc No: 01-649-850164-20230718
Version: 2.0
18 July 2023
Fortinet, Incorporated
899 Kifer Road
Sunnyvale, California, USA
94086
Prepared by:
Fortinet, Incorporated
16 Fitzgerald Rd.
Nepean, Ontario, Canada
K2H 8R6
Version: 2.0 Date: 18 July 2023 Page 1 of 60
CONTENTS
1 SECURITY TARGET INTRODUCTION............................................. 4
1.1 DOCUMENT ORGANIZATION ............................................................ 4
1.2 SECURITY TARGET REFERENCE........................................................ 5
1.3 TOE REFERENCE............................................................................. 5
1.4 TOE OVERVIEW.............................................................................. 5
TOE Features.................................................................................5
TOE Environment ...........................................................................7
1.5 TOE DESCRIPTION ......................................................................... 8
Physical Scope ...............................................................................8
TOE Interfaces...............................................................................8
Single-Unit Configuration ................................................................9
High-Availability Configuration ....................................................... 10
TOE Delivery ............................................................................... 11
Logical Scope............................................................................... 12
Functionality Excluded from the Evaluated Configuration................... 13
2 CONFORMANCE CLAIMS ............................................................ 15
2.1 COMMON CRITERIA CONFORMANCE CLAIM ..................................... 15
2.2 PROTECTION PROFILE CONFORMANCE CLAIM.................................. 15
2.3 PACKAGE CLAIM........................................................................... 15
2.4 CONFORMANCE RATIONALE........................................................... 15
3 SECURITY PROBLEM DEFINITION ............................................. 16
3.1 THREATS..................................................................................... 16
3.2 ORGANIZATIONAL SECURITY POLICIES .......................................... 16
3.3 ASSUMPTIONS ............................................................................. 17
4 SECURITY OBJECTIVES.............................................................. 18
4.1 SECURITY OBJECTIVES FOR THE TOE ............................................. 18
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT......... 18
4.3 SECURITY OBJECTIVES RATIONALE................................................ 19
Security Objectives Rationale Related to Threats.............................. 19
Security Objectives Rationale Related to OSPs ................................. 22
Security Objectives Rationale Related to Assumptions....................... 23
5 EXTENDED COMPONENTS DEFINITION...................................... 25
5.1 SECURITY FUNCTIONAL REQUIREMENTS......................................... 25
5.2 CLASS FAV: ANTI-VIRUS............................................................... 25
FAV_SIG_EXT Anti-Virus Signature Protection.................................. 25
Version: 2.0 Date: 18 July 2023 Page 2 of 60
5.3 CLASS FIP: INTRUSION PREVENTION ............................................. 26
FIP_DOS_EXT Denial of Service Prevention...................................... 26
FIP_SIG_EXT Intrusion Prevention Signature Protection .................... 26
5.4 SECURITY ASSURANCE REQUIREMENTS.......................................... 27
6 SECURITY REQUIREMENTS........................................................ 28
6.1 CONVENTIONS............................................................................. 28
6.2 SECURITY FUNCTIONAL REQUIREMENTS......................................... 28
Security Audit (FAU)..................................................................... 29
Cryptographic Support (FCS) ......................................................... 31
User Data Protection (FDP)............................................................ 32
Identification and Authentication (FIA)............................................ 34
Security Management (FMT) .......................................................... 35
Protection of the TSF (FPT)............................................................ 37
Trusted Path/Channels (FTP) ......................................................... 37
Intrusion Prevention (FIP) (EXT) .................................................... 38
Anti-Virus Requirements (FAV) (EXT).............................................. 38
6.3 SECURITY ASSURANCE REQUIREMENTS.......................................... 39
6.4 SECURITY REQUIREMENTS RATIONALE........................................... 39
Security Functional Requirements Rationale..................................... 39
SFR Rationale Related to Security Objectives ................................... 41
Dependency Rationale .................................................................. 44
Security Assurance Requirements Rationale..................................... 46
7 TOE SUMMARY SPECIFICATION................................................. 47
7.1 SECURITY AUDIT.......................................................................... 47
7.2 CRYPTOGRAPHIC SUPPORT............................................................ 47
7.3 USER DATA PROTECTION .............................................................. 47
7.4 IDENTIFICATION AND AUTHENTICATION ........................................ 49
7.5 SECURITY MANAGEMENT............................................................... 50
7.6 PROTECTION OF THE TSF.............................................................. 50
7.7 TRUSTED PATH / CHANNELS.......................................................... 51
7.8 INTRUSION PREVENTION .............................................................. 52
7.9 ANTI-VIRUS................................................................................. 52
8 TERMINOLOGY AND ACRONYMS................................................ 53
8.1 TERMINOLOGY ............................................................................. 53
8.2 ACRONYMS.................................................................................. 54
9 ANNEX A – FORTIGATE MODELS, GUIDES, ASIC/ENTROPY SOURCE
AND CPU .............................................................................................. 56
Version: 2.0 Date: 18 July 2023 Page 3 of 60
9.1 HARDWARE MODELS..................................................................... 56
9.2 VIRTUAL MODELS......................................................................... 60
LIST OF TABLES
Table 1 - TOE Features ................................................................................. 7
Table 2 – Non-TOE Hardware and Software ..................................................... 8
Table 3 – Logical Scope of the TOE............................................................... 13
Table 4 – Threats ....................................................................................... 16
Table 5 – Organizational Security Policies...................................................... 17
Table 6 – Assumptions................................................................................ 17
Table 7 – Security Objectives for the TOE...................................................... 18
Table 8 – Security Objectives for the Operational Environment ........................ 19
Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions.......... 19
Table 10 – Summary of Security Functional Requirements............................... 29
Table 11 - Auditable Events......................................................................... 30
Table 12 - Cryptographic Operations............................................................. 32
Table 13 – Security Assurance Requirements................................................. 39
Table 14 – Mapping of SFRs to Security Objectives......................................... 40
Table 15 – Functional Requirement Dependencies .......................................... 45
Table 16 – Terminology .............................................................................. 53
Table 17 – Acronyms .................................................................................. 55
Table 18 - Hardware Models, Guides, ASIC/Entropy Source and CPU ................ 60
Table 19 - Virtual Models, Guides and Entropy Source .................................... 60
LIST OF FIGURES
Figure 1 – Single-Unit Configuration ............................................................. 10
Figure 2 - HA Configuration ......................................................................... 11
Figure 3 – FAV_SIG_EXT: Anti-Virus Signature Protection Component Levelling . 25
Figure 4 – FIP_DOS_EXT: Denial of Service Component Levelling..................... 26
Figure 5 – FIP_SIG_EXT: Intrusion Prevention Signature Protection Component
Levelling .............................................................................................. 26
Version: 2.0 Date: 18 July 2023 Page 4 of 60
1 SECURITY TARGET INTRODUCTION
This Security Target (ST) defines the scope of the evaluation in terms of the
assumptions made, the intended environment for the Target of Evaluation (TOE),
the Information Technology (IT) security functional and assurance requirements to
be met, and the level of confidence (evaluation assurance level) to which it is
asserted that the TOE satisfies its IT security requirements. This document forms
the baseline for the Common Criteria (CC) evaluation.
1.1 DOCUMENT ORGANIZATION
Section 1, ST Introduction, provides the Security Target reference, the Target
of Evaluation reference, the TOE overview and the TOE description.
Section 2, Conformance Claims, describes how the ST conforms to the
Common Criteria and Packages. The ST does not conform to a Protection
Profile.
Section 3, Security Problem Definition, describes the expected environment in
which the TOE is to be used. This section defines the set of threats that are
relevant to the secure operation of the TOE, organizational security policies with
which the TOE must comply, and secure usage assumptions applicable to this
analysis.
Section 4, Security Objectives, defines the set of security objectives to be
satisfied by the TOE and by the TOE operating environment in response to the
problem defined by the security problem definition.
Section 5, Extended Components Definition, defines the extended
components which are then detailed in Section 6.
Section 6, Security Requirements, specifies the security functional and
assurance requirements that must be satisfied by the TOE and the IT
environment.
Section 7, TOE Summary Specification, describes the security functions that
are included in the TOE to enable it to meet the IT security functional
requirements.
Section 8, Terminology and Acronyms, defines the acronyms and terminology
used in this ST.
Section 9, Annex A, identifies the TOE hardware models, guides, and entropy
sources.
Version: 2.0 Date: 18 July 2023 Page 5 of 60
1.2 SECURITY TARGET REFERENCE
ST Title: FortiOS® 6.4 Security Target
ST Version: 2.0
ST Date: 18 July 2023
1.3 TOE REFERENCE
TOE Identification: FortiOS 6.4.9 (FIPS-CC-64-7)
TOE Developer: Fortinet, Incorporated
TOE Type: Boundary Protection Device
1.4 TOE OVERVIEW
FortiOS provides firewall, Virtual Private Network (VPN), Virtual Local Area
Network (VLAN), antivirus protection, antispam protection and content filtering to
provide network protection for Internet Protocol version 4 (IPv4) and Internet
Protocol version 6 (IPv6) networks.
FortiOS supports a full range of network environments, from the remote office and
branch office (ROBO) to service provider, offering solutions for any size of
application. FortiOS is designed to protect computer networks from abuse.
FortiOS firewalls are deployed between the network they are protecting and an
external network, such as the Internet, restricting the information flow between
them permitted by policies (set of rules) defined by an authorized administrator.
FortiOS detects and eliminates the most damaging, content-based threats from
email and Web traffic such as viruses, worms, and intrusions in real-time, without
degrading network performance. In addition to providing application-level
protection, FortiOS delivers a full range of network-level services including: VPN,
VLAN, Network Address Translation (NAT), intrusion protection, web filtering,
antivirus, antispam, and traffic shaping.
FortiOS can be deployed on a dedicated FortiGate appliance or as a virtual
machine running on VMware ESXi. Administration of the system may be
performed locally using an administrator console, or remotely via a network
management workstation. FortiOS firewalls can operate either standalone or as
part of a cluster in order to provide high availability of services.
FortiOS supports the Internet Protocol Security (IPsec) industry standard for VPN,
allowing VPNs to be configured between a FortiOS firewall and any
gateway/firewall that supports IPsec VPN.
The TOE supports the FortiGate appliance models identified in ANNEX A Table 18.
Table 19 identifies the VMware ESXi Virtual Machine (VM) variants of the TOE.
Note: The TOE is the FortiOS firmware and does not include the FortiGate or
hypervisor hardware. The hardware appliances and hypervisor hardware are in the
(operational) environment.
TOE Features
The function of FortiOS is to isolate two or more networks from each other and
arbitrate the information transfers between these networks. Arbitration is based
on a set of policies (rules) that are established by an authorized administrator and
Version: 2.0 Date: 18 July 2023 Page 6 of 60
applied to each data packet that flows through the system. The TOE arbitrates all
data that travels through it from one network to another.
FortiOS has a FIPS-CC Mode of operation which, when enabled by an authorized
administrator, provides the capability claimed in this ST. FIPS-CC Mode provides
initial default values and enforces the FIPS-CC configuration requirements.
The following table summarizes the most security-relevant FortiGate features.
Feature Description
Access Control FortiOS provides a role-based access control capability to
ensure that only authorized administrators are able to
administer the FortiGate unit.
Administration (Local
Console CLI)
The FortiOS provides management capabilities via the text-
based Local Console Command Line Interface (CLI).
Administration
(Network Web-Based
GUI)
FortiOS provides a Network Web-based Graphical User
Interface (GUI), accessed via HyperText Transfer Protocol
Secure (HTTPS), for system management and configuration.
Administration (SSH) FortiOS provides remote administration services over Secure
Shell (SSH) for system management and configuration.
Anti-Virus FortiOS provides anti-virus protection for HyperText Transfer
Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail
Transfer Protocol (SMTP), Post-Office Protocol Version 3
(POP3), and Internet Message Access Protocol (IMAP) Web
content as it passes through the FortiGate unit.
Authentication FortiOS implements a username and password mechanism for
identification and authentication.
Authentication
(Firewall Policy
Authentication)
FortiOS policies may be configured to require authentication by
the user before the information flow is enabled for that user.
Cryptography FortiOS incorporates cryptographic operations for protecting
communication channels.
Firewall (Information
Flow Control)
FortiOS implements a stateful traffic filtering firewall.
Information flow is restricted to that permitted by a policy (set
of rules) defined by an authorized administrator. The default
policy is restrictive (i.e., no traffic flows without administrator
action to configure policy).
FortiGuard Web
Filtering
When a request for a web page appears in traffic controlled by
FortiOS, the Universal Resource Locator (URL) is sent to a
FortiGuard server and the URL category is returned. The
FortiGate unit determines if the URL should be allowed or
blocked based on the category and the implemented policy.
High Availability FortiOS provides a high availability capability between two or
more identical units communicating via the FortiGate clustering
protocol. Two modes of operation are supported: active-
passive for failover protection and active-active for failover
protection and load balancing.
Intrusion Prevention
System
FortiOS uses signatures to detect and prevent attacks to the
data passing through them. The IPS attack signatures may be
updated manually or FortiOS may be configured to
automatically download updates. The TOE also includes local
anomaly detection to protect itself from direct attacks such as
denial of service (DoS) attacks.
Version: 2.0 Date: 18 July 2023 Page 7 of 60
Feature Description
IPv6 Both an IPv4 and an IPv6 address may be assigned to any
interface on a FortiGate unit. The interface functions as two
interfaces; one for IPv4-addressed packets and another for
IPv6-addressed packets. FortiOS supports static routing,
periodic router advertisements, and tunnelling of IPv6-
addressed traffic over an IPv4-addressed network. All relevant
security claims apply to IPv4 and IPv6.
Logging
(management)
FortiOS supports management activities for configuration and
management of logging.
Logging (recording) Logging is performed and data is either stored locally or
transferred to an external log server such as FortiAnalyzer1
.
Protection Profile2
Protection profiles are used to configure anti-virus protection,
and IPS.
Static Routing Static routes are configured by defining the destination IP
address and netmask of packets that FortiOS is intended to
intercept, and specifying a (gateway) IP address for those
packets. The gateway address specifies the next-hop router to
which traffic will be routed.
Time FortiOS maintains internal time on a system clock, settable by
an authorized administrator. This clock is used when time
stamps are generated.
VLAN FortiOS supports VLAN as a sub interface attached to a
physical interface port. The firewall rules detailed herein may
be applied to VLANs.
VPN FortiOS supports IPsec VPN to provide a secure connection
between widely separated office networks or to securely link
telecommuters or travellers to an office network.
Table 1 - TOE Features
TOE Environment
The following components are required for operation of the TOE in the evaluated
configuration.
1
A FortiAnalyzer server can provide real-time log review and is a supported but not
evaluated component of the FortiGate TOE.
2
The term ‘Protection Profile’ is the name given to a set of Fortinet security rules and
should not be confused with Common Criteria PPs.
Version: 2.0 Date: 18 July 2023 Page 8 of 60
Component Operating System Hardware
FortiGate Hardware
appliance
FortiOS (the TOE) FortiGate Hardware appliance
Management
Workstation
Windows 10
supporting a web
browser and terminal
application
General Purpose Computer Hardware
FortiGuard Distribution
Server
N/A General Purpose Computer Hardware
VMware Server (for
FortiGate VM Models)
ESXi 6.7 General Purpose Computer Hardware
(see list of virtual models in Table 19)
VPN Client Windows 10 with VPN
client
General Purpose Computer Hardware
Entropy Token N/A Araneus Alea II True Random
Number Generator (TRNG) Hardware
Token
Table 2 – Non-TOE Hardware and Software
1.5 TOE DESCRIPTION
Physical Scope
FortiOS is deployed on a FortiGate appliance or as a VM running on ESXi VMware
Server. (For the complete list of models, firmware and guidance see the list in
Appendix A). Each FortiGate appliance consists of custom hardware, with the
exception of the FortiGate-VM models, which do not include the hardware. The
FortiGate unit consists of the following major components: processors, memory,
mass storage, FortiASIC™ processors, and input/output interfaces.
TOE Interfaces
The TOE can be securely administered over the external or internal networks, or
locally within the secure area. The TOE provides the following administration
options:
 RS-232 console support is available on all FortiGate models and can be
mapped through the hypervisor on FortiGate-VM models. When connected
to a terminal which supports VT100 emulation, the console port allows
access to FortiOS via the Local Console CLI. This permits an authorized
administrator to configure the TOE, monitor its operation, and examine the
audit logs that are created.
 Administration may be performed on all models through a dedicated
management network port that has been configured by an authorized
administrator to allow HTTPS for the Network Web-Based GUI.
 Remote administration may be performed on all models using Secure Shell
(SSH) on port 22.
 FortiOS supports Universal Serial Bus (USB) port(s) that may be used by an
authorized administrator to connect the hardware entropy source (if
required by the FortiGate model).
Version: 2.0 Date: 18 July 2023 Page 9 of 60
 An authorized administrator may configure automatic Anti-Virus and
Intrusion Prevention System (IPS) updates from the FortiGuard Distribution
Server.
FortiOS is designed to be installed and used in an environment that is configured
and controlled in accordance with the administrator guidance that is supplied with
the product.
Single-Unit Configuration
In the single-unit configuration, the TOE consists of FortiOS running on a single
FortiGate unit or FortiGate-VM installation. The TOE controls network access by
implementing classic firewall concepts, in which the firewall is linked to two or
more networks and controls the transfer of data between them. The configuration
supports additional networks, each of which is physically connected to one of the
included network interfaces. Figure 1 shows an example of a single TOE
installation mediating information flow between two networks. One of the
networks provides access to the FortiGuard Distribution Server, which permits
Anti-Virus and IPS updates to be downloaded and facilitates access to Web
filtering data.
The Management Workstation is a general-purpose computer with a standard
network interface used to administer the TOE using the Network Web-based GUI
or over SSH. A standard serial interface may also be used to administer the TOE
locally.
The TOE accesses the FortiGuard Distribution Server, which permits Anti-Virus and
Intrusion Detection System/Intrusion Prevention System (IDS/IPS) updates to be
downloaded by the TOE.
The TOE can act as a secure gateway for remote clients through an IPsec VPN
tunnel.
Note: The gateway to gateway configuration is not depicted in Figure 1.
Version: 2.0 Date: 18 July 2023 Page 10 of 60
Figure 1 – Single-Unit Configuration
High-Availability Configuration
In the High Availability (HA) configuration, which is supported by all FortiGate
units and FortiGate-VM models, the TOE consists of FortiOS running on two or
more FortiGate units or FortiGate-VM models interconnected to form an HA
cluster. The cluster controls network access by implementing classic firewall
concepts, in which the firewall is linked to two or more networks and controls the
transfer of data between them. The configuration supports additional networks,
each of which is physically connected to one of the included network interfaces.
Figure 2 shows FortiOS running on two FortiGate units of the same type
configured in HA mode to form a cluster. A cluster may be configured to work in
active-passive mode for failover protection, or in active-active mode for failover
protection and load balancing. Both active-passive mode and active-active mode
are part of the evaluated configuration of the TOE. The cluster units share state
and configuration information over a dedicated High Availability Link. The TOE
accesses the FortiGuard Distribution Server, which permits Anti-Virus and
Intrusion Detection System/Intrusion Prevention System (IDS/IPS) updates to be
downloaded.
The Management Workstation is present as per the single-unit configuration.
Version: 2.0 Date: 18 July 2023 Page 11 of 60
Figure 2 - HA Configuration
TOE Delivery
FortiGate units are shipped directly to customers, but the certified FortiOS image
is not preinstalled. Customers can download the correct version by logging in to
the Fortinet Customer Support website (https://support.fortinet.com
[support.fortinet.com]) and navigating to Download > Firmware Images.
Due to having different device drivers, each model has its own unique firmware
image created from the same common source code. Customers can download the
image based on their FortiGate model. The images are provided to customers as a
.out file. An example of a filename is as follows:
 FGT_301E-v6-build9451-FORTINET.out
1.5.5.1 TOE Guidance
All guidance documentation is available for download in Portable Document Format
(PDF) format at: https://docs.fortinet.com/product/FortiGate/6.4.
The TOE includes the following guidance documentation:
 FortiOS – Administration Guide, Version 6.4.9, August 22, 2022, 01-649-
607590-20220822
 FortiOS – CLI Reference, Version 6.4.9, April 26, 2022, 01-649-684766-
20220426
 FortiOS - Log Reference, Version 6.4.9, May 20, 2022, 01-649-619093-
20220520
 FortiOS – Release Notes, Version 6.4.9, June 27, 2023, 01-649-764531-
20230627
Version: 2.0 Date: 18 July 2023 Page 12 of 60
In addition to the above, a series of hardware model specific informational and
quick start guides are available from the Fortinet Docs Library site at:
https://docs.fortinet.com/product/fortigate/hardware
A link to these guides is provided in Table 18 (for hardware models) and Table 19
(for virtual models).
The following FIPS and Common Criteria Guidance Supplement is also available to
customers, in Portable Document Format (PDF) format, along with the firmware in
the specific FIPS-CC-Certified folder on https://support.fortinet.com:
 FortiOS 6.4 and 7.0 EAL4 Common Criteria Technote, July 18, 2023, 01-
649/707-817723-20230718
Logical Scope
The logical boundary of the TOE includes all interfaces and functions within the
physical boundary. The logical boundary of the TOE may be broken down by the
security function classes described in Section 6. Table 3 summarizes the logical
scope of the TOE.
Functional Classes Description
Security Audit The TOE generates audit records for security relevant
events.
Cryptographic Support Cryptographic functionality is provided to protect
communications for remote administration, VPN, and peer-
to-peer connections within a cluster.
User Data Protection The TOE provides interfaces to a defined set of networks
and mediates information flow among these networks. The
TOE supports firewall and web filtering policies.
Identification and
Authentication
All TOE administrative users must be identified and
authenticated. Administration may be performed locally
using the Local Console CLI, remotely using the Network
Web-based GUI on a dedicated management port, or
remotely over SSH. TOE users may be required to
authenticate in order to access an internal or external
network. The TOE blocks users after a configurable number
of authentication failures.
Version: 2.0 Date: 18 July 2023 Page 13 of 60
Functional Classes Description
Security Management The TOE provides administrative interfaces that permit
users in administrative roles to configure and manage the
TOE. In each of the two evaluated configurations (i.e., the
Single-Unit Configuration and High-Availability
Configuration), the TOE is connected to two or more
networks and remote administration data flows from a
Network Management workstation to the TOE. In each
configuration there is also a Local Console, located within a
Secure Area, with an interface to the TOE.
An administrator account is associated with an access
profile which determines the permissions of the individual
administrator. Additionally, each FortiGate unit comes with
a default administrator account with all permissions, which
may not be deleted.
The terms ‘administrator’ and ‘authorized administrator’ are
used throughout this ST to describe an administrator given
the appropriate permission to perform tasks as required.
Protection of the TSF The TOE provides failover in support of the high availability
features. Reliable time stamps are provided in support of
the audit function.
Trusted Path/Channel A trusted path communication is required for the
authentication of administrators and users of TOE services
that require authentication. A remote administrator’s
communication remains encrypted throughout the remote
session.
The TOE requires an encrypted trusted channel for
communication between VPN peers (client or gateway) and
TLS connections.
The TOE requires an encrypted trusted channel for
communication between FortiGate devices in support of the
High Availability configuration.
Anti-Virus The TOE supports anti-virus detection and the ability to
block or quarantine suspected information. A secure
mechanism is used to update virus signatures.
Intrusion Prevention The TOE provides IPS functionality to recognize and block
potential Denial of Service attacks, and to recognize and
block attacks based on known intrusion attack signatures.
Table 3 – Logical Scope of the TOE
Functionality Excluded from the Evaluated
Configuration
1.5.7.1 Excluded Features
The following TOE features are excluded from this evaluation:
 Centralized management of the TOE by FortiManager servers
 The TOE’s antispam, content filtering and traffic shaping features
 SMTP, SNMP, LDAP, Windows AD, NTP, and Radius
 FortiGuard-Antispam, Firmware, Endpoint Control, and FortiSandbox
services
Version: 2.0 Date: 18 July 2023 Page 14 of 60
 The TOE’s DHCP, DDNS, or DNS server capabilities
 Traffic offloading to the FortiASIC NPx network processors
 Routing protocols (RIP, OSPF, BGP)
 SSL VPN
 Use of the USB interface for anything other than an Entropy Token
 Diagnostics interface
 FortiAnalyzer, Syslog
1.5.7.2 Disabled Features
The following TOE features are disabled by default and are excluded from the
scope of this evaluation:
 HTTP GUI
 The TOE acting as a Telnet client or server
 The FortiGate REST API
 The TOE acting as a TFTP client
Version: 2.0 Date: 18 July 2023 Page 15 of 60
2 CONFORMANCE CLAIMS
2.1 COMMON CRITERIA CONFORMANCE CLAIM
This Security Target claims to be conformant to Version 3.1 of Common Criteria
for Information Technology Security Evaluation according to:
 Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model; CCMB-2017-04-001, Version 3.1, Revision
5, April 2017
 Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components; CCMB-2017-04-002, Version 3.1, Revision
5, April 2017
 Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components CCMB-2017-04-003, Version 3.1, Revision
5, April 2017
As follows:
 CC Part 2 extended
 CC Part 3 conformant
The Common Methodology for Information Technology Security Evaluation,
Version 3.1, Revision 5, April 2017 has been taken into account.
2.2 PROTECTION PROFILE CONFORMANCE CLAIM
This ST does not claim conformance of the TOE with any Protection Profile (PP).
2.3 PACKAGE CLAIM
This Security Target claims conformance to Evaluation Assurance Level 4
augmented with ALC_FLR.3 Systematic Flaw Remediation.
2.4 CONFORMANCE RATIONALE
This ST does not claim conformance of the TOE with any PP, therefore a
conformance rationale is not applicable.
Version: 2.0 Date: 18 July 2023 Page 16 of 60
3 SECURITY PROBLEM DEFINITION
3.1 THREATS
Table 4 lists the threats addressed by the TOE. Potential threat agents are
unauthorized persons or external IT entities not authorized to use the TOE itself.
The threat agents are assumed to have a low to moderate attack potential and are
assumed to have a moderate level of resources and access to all publicly available
information about the TOE and potential methods of attacking the TOE. It is
expected that the FortiGate units will be protected to the extent necessary to
ensure that they remain connected to the networks they protect.
Mitigation to the threats is through the objectives identified in Section 4.1,
Security Objectives for the TOE.
Threat Description
T.ACCESS An unauthorized person on an external network may attempt to bypass the
information flow control policy to access protected resources on the internal
network.
T.AUDACC Persons may not be accountable for the actions that they conduct because the
audit records are not created, thus allowing an attacker to escape detection.
T.COMDIS An unauthorized user may attempt to disclose the data collected by the TOE
by bypassing a security mechanism.
T.MEDIATE An unauthorized person may attempt to send impermissible information
through the TOE, which could result in the exploitation of resources on the
internal network.
T.NOAUTH An unauthorized person may attempt to bypass the security of the TOE so as
to access and use security functions and/or non-security functions provided
by the TOE.
T.NOHALT An unauthorized user may attempt to compromise the continuity of the TOE
functionality by halting execution of the TOE.
T.PRIVILEGE An unauthorized user may attempt to gain access to the TOE and exploit
system privileges to gain access to TOE security functions and data.
T.PROCOM An unauthorized person or unauthorized external IT entity may be able to
view, modify, and/or delete security related information that is sent between
a remotely located authorized administrator and the TOE, between VPN peers
and the TOE, or between TOE devices.
T.VIRUS A malicious agent may attempt to pass a virus through or to the TOE.
Table 4 – Threats
3.2 ORGANIZATIONAL SECURITY POLICIES
Organizational Security Policies (OSPs) are security rules, procedures, or
guidelines imposed on the operational environment. Table 5 lists the OSPs that
are presumed to be imposed upon the TOE or its operational environment by an
organization that implements the TOE in the Common Criteria evaluated
configuration.
OSP Description
P.ACCACT Users of the TOE shall be accountable for their actions.
P.DETECT All events that are indicative of inappropriate activity that may have resulted
from misuse, access, or malicious activity must be collected.
Version: 2.0 Date: 18 July 2023 Page 17 of 60
OSP Description
P.MANAGE The TOE shall be manageable only by authorized administrators.
Table 5 – Organizational Security Policies
3.3 ASSUMPTIONS
The assumptions required to ensure the security of the TOE are listed in Table 6.
Assumptions Description
A.LOCATE The hardware appliances will be located within controlled access facilities and
protected from unauthorized physical or logical modifications. A dedicated
port on the TOE is plugged to the out-of-band management network used by
administrators to connect to the HTTPS Web GUI of the TOE.
A.MANAGE There will be one or more competent individuals assigned to manage the TOE
and the security of the information it contains.
A.SINGEN Information cannot flow among the internal and external networks unless it
passes through the TOE.
Table 6 – Assumptions
Version: 2.0 Date: 18 July 2023 Page 18 of 60
4 SECURITY OBJECTIVES
The purpose of the security objectives is to address the security concerns and to
show which security concerns are addressed by the TOE, and which are addressed
by the environment. Threats may be addressed by the TOE or the security
operational environment or both. Therefore, the CC identifies two categories of
security objectives:
 Security objectives for the TOE
 Security objectives for the operational environment
4.1 SECURITY OBJECTIVES FOR THE TOE
This section identifies and describes the security objectives that are to be
addressed by the TOE.
Security Objective Description
O.ACCESS The TOE must allow only authorized users to access only appropriate
TOE functions and data.
O.ADMIN The TOE must provide functionality that enables an authorized
administrator to manage TOE security functions, and must ensure
that only authorized administrators are able to access such
functionality.
O.AUDIT The TOE must provide user accountability for information flows
through the TOE and for authorized administrator use of security
functions by providing a means to record an audit trail of security-
related events, with accurate dates and times.
O.ENCRYPT The TOE must protect the confidentiality and integrity of data passed
between itself and an authorized administrator, between itself and
VPN peers, or between TOE devices using cryptographic functions.
O.IDENTAUTH The TOE must be able to identify and authenticate authorized users
prior to allowing access to TOE security management functions or, if
required, to a connected network.
O.MEDIATE The TOE must mediate the flow of all information between clients
and servers located on internal and external networks governed by
the TOE.
O.PROTECT The TOE must protect itself and the designated network against
attempts by unauthorized users to bypass, deactivate, or tamper
with TOE security functions in such a way as to cause unauthorized
access to its functions and data, or to deny access to legitimate
users.
O.REUSE The TOE must provide a means to prevent the reuse of authentication
data for users attempting to authenticate to the TOE from a connected
network.
O.TIME The TOE shall provide reliable time stamps.
O.VIRUS The TOE will detect and block viruses contained within an information
flow which arrives at any of the TOE network interfaces.
Table 7 – Security Objectives for the TOE
4.2 SECURITY OBJECTIVES FOR THE
OPERATIONAL ENVIRONMENT
This section identifies and describes the security objectives that are to be
addressed by the IT environment or by non-technical or procedural means.
Version: 2.0 Date: 18 July 2023 Page 19 of 60
Security Objective Description
OE.ADMIN Those responsible for the TOE must ensure that the TOE is delivered,
installed, managed, and operated in a manner which is consistent with
IT security. There are an appropriate number of authorized
administrators trained to maintain the TOE, including its security
policies and practices. Authorized administrators are non-hostile and
follow all administrator guidance.
OE.PHYSICAL Those responsible for the TOE must ensure that the TOE is protected
from any physical attack.
OE.MANAGEMENT HTTPS access to the Web GUI for management of the TOE must only
be allowed through the dedicated management network port. Only
trusted administrators have physical access to the management
network.
OE.SINGEN Information cannot flow among the internal and external networks
unless it passes through the TOE.
Table 8 – Security Objectives for the Operational Environment
4.3 SECURITY OBJECTIVES RATIONALE
The following table maps the security objectives to the assumptions, threats, and
organizational policies identified for the TOE.
T.ACCESS
T.AUDACC
T.COMDIS
T.MEDIATE
T.NOAUTH
T.NOHALT
T.PRIVILEGE
T.PROCOM
T.VIRUS
P.ACCACT
P.DETECT
P.MANAGE
A.LOCATE
A.MANAGE
A.SINGEN
O.ACCESS X X X X
O.ADMIN X X
O.AUDIT X X X
O.ENCRYPT X X
O.IDENTAUTH X X X X X X
O.MEDIATE X X
O.PROTECT X X X X
O.REUSE X
O.TIME X X
O.VIRUS X
OE.ADMIN X X
OE.PHYSICAL X
OE.MANAGEMENT X
OE.SINGEN X
Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions
Security Objectives Rationale Related to Threats
The security objectives rationale related to threats traces the security objectives
for the TOE and the Operational Environment back to the threats addressed by the
TOE.
Threat: T.ACCESS An unauthorized person on an external network may attempt to bypass
the information flow control policy to access protected resources on the
internal network.
Version: 2.0 Date: 18 July 2023 Page 20 of 60
Objectives: O.MEDIATE The TOE must mediate the flow of all information
between clients and servers located on internal and
external networks governed by the TOE.
Rationale: O.MEDIATE mitigates this threat by ensuring that all information
between clients and servers located on internal and external networks is
mediated by the TOE.
Threat: T.AUDACC Persons may not be accountable for the actions that they conduct
because the audit records are not created, thus allowing an attacker to
escape detection.
Objectives: O.ADMIN The TOE must provide functionality that enables an
authorized administrator to manage TOE security
functions, and must ensure that only authorized
administrators are able to access such functionality.
O.AUDIT The TOE must provide user accountability for
information flows through the TOE and for authorized
administrator use of security functions by providing a
means to record an audit trail of security-related events,
with accurate dates and times.
Rationale: O.ADMIN provides for security management functionality.
O.AUDIT requires that users are accountable for information flows
through the TOE and that authorized administrators are accountable for
the use of security functions related to audit.
Threat: T.COMDIS An unauthorized user may attempt to disclose the data collected by the
TOE by bypassing a security mechanism.
Objectives: O.ACCESS The TOE must allow only authorized users to access only
appropriate TOE functions and data.
O.IDENTAUT
H
The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE security
management functions or, if required, to a connected
network.
O.PROTECT The TOE must protect itself and the designated network
against attempts by unauthorized users to bypass,
deactivate, or tamper with TOE security functions in
such a way as to cause unauthorized access to its
functions and data, or to deny access to legitimate
users.
Rationale: The O.IDENTAUTH objective provides for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the
O.IDAUTH objective by only permitting authorized users to access TOE
data.
The O.PROTECT objective addresses this threat by providing TOE self-
protection.
Threat:
T.MEDIATE
An unauthorized person may attempt to send impermissible information
through the TOE, which could result in the exploitation of resources on
the internal network.
Objectives: O.MEDIATE The TOE must mediate the flow of all information
between clients and servers located on internal and
external networks governed by the TOE.
Rationale: O.MEDIATE requires that all information that passes through the
networks is mediated by the TOE, blocking unauthorized users, and
impermissible information.
Version: 2.0 Date: 18 July 2023 Page 21 of 60
Threat:
T.NOAUTH
An unauthorized person may attempt to bypass the security of the TOE
so as to access and use security functions and/or non-security functions
provided by the TOE.
Objectives: O.ENCRYPT The TOE must protect the confidentiality and integrity
of data passed between itself and an authorized
administrator, between itself and VPN peers, or
between TOE devices using cryptographic functions.
O.IDENTAUTH The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE
security management functions or, if required, to a
connected network.
O.REUSE The TOE must provide a means to prevent the reuse of
authentication data for users attempting to
authenticate to the TOE from a connected network.
Rationale: O.IDENTAUTH requires that users be uniquely identified before
accessing the TOE.
O.ENCRYPT ensures the confidentiality and integrity of data passed
between the TOE and the authorized administrator, between itself and
VPN peers, and between TOE devices.
O.REUSE ensures there is no reuse of authentication data by leveraging
a single use authentication token device.
Threat: T.NOHALT An unauthorized user may attempt to compromise the continuity of the
TOE functionality by halting execution of the TOE.
Objectives: O.ACCESS The TOE must allow authorized users to access only
appropriate TOE functions and data.
O.IDENTAUTH The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE
security management functions or, if required, to a
connected network.
O.PROTECT The TOE must protect itself and the designated
network against attempts by unauthorized users to
bypass, deactivate, or tamper with TOE security
functions in such a way as to cause unauthorized
access to its functions and data, or to deny access to
legitimate users.
Rationale: The O.IDENTAUTH objective provides for authentication of users prior to
any TOE function accesses. The O.ACCESS objective builds upon the
O.IDENTAUTH objective by only permitting authorized users to access
TOE functions.
The O.PROTECT objective addresses this threat by requiring the TOE to
protect itself against bypass, or to deny access to legitimate users.
Threat:
T.PRIVILEGE
An unauthorized user may attempt to gain access to the TOE and
exploit system privileges to gain access to TOE security functions and
data.
Objectives: O.ACCESS The TOE must allow authorized users to access only
appropriate TOE functions and data.
O.IDENTAUTH The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE
functions, data or, for certain specified services, to a
connected network.
O.PROTECT The TOE must protect itself from unauthorized
modifications and access to its functions and data.
Version: 2.0 Date: 18 July 2023 Page 22 of 60
Rationale: The O.IENTDAUTH objective provides for authentication of users prior to
any TOE function accesses. The O.ACCESS objective builds upon the
O.IENTDAUTH objective by only permitting authorized users to access
TOE functions.
The O.PROTECT objective addresses this threat by providing TOE self-
protection.
Threat:
T.PROCOM
An unauthorized person or unauthorized external IT entity may be able
to view, modify, and/or delete security related information that is sent
between a remotely located authorized administrator and the TOE,
between VPN peers and the TOE, or between TOE devices.
Objectives: O.ENCRYPT The TOE must protect the confidentiality and integrity
of data passed between itself and an authorized
administrator, between itself and VPN peers, or
between TOE devices using cryptographic functions.
Rationale: O.ENCRYPT requires encryption for remote administration of the TOE,
VPN use, and communications between TOE devices.
Threat: T.VIRUS A malicious agent may attempt to pass a virus through or to the TOE.
Objectives: O.VIRUS The TOE will detect and block viruses contained within
an information flow which arrives at any of the TOE
network interfaces.
Rationale: The O.VIRUS objective ensures that the TOE detects and blocks viruses
which are contained in any information flow which reaches one of the
TOE network interfaces.
Security Objectives Rationale Related to OSPs
The security objectives rationale related to OSPs traces the security objectives for
the TOE and the Operational Environment back to the OSPs applicable to the TOE.
Policy: P.ACCACT Users of the TOE shall be accountable for their actions.
Objectives: O.AUDIT The TOE must provide user accountability for
information flows through the TOE and for authorized
administrator use of security functions by providing a
means to record an audit trail of security-related events,
with accurate dates and times.
O.IDENTAUTH The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE
functions, data or, for certain specified services, to a
connected network.
O.TIME The TOE shall provide reliable time stamps and the
capability for the administrator to set the time used for
these time stamps.
Rationale: The O.AUDIT objective implements this policy by requiring auditing of all
data accesses and use of TOE functions.
The O.IDENTAUTH objective supports this objective by ensuring each
user is uniquely identified and authenticated.
O.TIME supports the audit trail with reliable time stamps.
Policy: P.DETECT All events that are indicative of inappropriate activity that may have
resulted from misuse, access, or malicious activity must be collected.
Objectives: O.AUDIT The TOE must provide user accountability for
information flows through the TOE and for authorized
administrator use of security functions by providing a
Version: 2.0 Date: 18 July 2023 Page 23 of 60
means to record an audit trail of security-related events,
with accurate dates and times.
O.TIME The TOE shall provide reliable time stamps.
Rationale: The O.AUDIT objective supports this policy by ensuring the collection of
data on security relevant events.
O.TIME supports this policy by ensuring that the audit functionality is
able to include reliable timestamps.
Policy: P.MANAGE The TOE shall be manageable only by authorized administrators.
Objectives: O.ACCESS The TOE must allow authorized users to access only
appropriate TOE functions and data.
O.ADMIN The TOE must provide functionality that enables an
authorized administrator to manage TOE security
functions, and must ensure that only authorized
administrators are able to access such functionality.
O.IDENTAUTH The TOE must be able to identify and authenticate
authorized users prior to allowing access to TOE
security management functions or, if required, to a
connected network.
O.PROTECT The TOE must protect itself and the designated
network against attempts by unauthorized users to
bypass, deactivate, or tamper with TOE security
functions in such a way as to cause unauthorized
access to its functions and data, or to deny access to
legitimate users.
OE.ADMIN Those responsible for the TOE must ensure that the
TOE is delivered, installed, managed, and operated in a
manner which is consistent with IT security. There are
an appropriate number of authorized administrators
trained to maintain the TOE, including its security
policies and practices. Authorized administrators are
non-hostile and follow all administrator guidance.
Rationale: The O.ACCESS objective supports this policy by ensuring that
authorized administrators have appropriate access to manage the TOE.
O.ADMIN supports this policy by ensuring that the TOE provides the
appropriate security management functionality to authorized
administrators.
O.IDENTAUTH supports this policy by ensuring that administrators must
be identified and authenticated prior to being granted access to TOE
security management functions.
O.PROTECT supports this policy by ensuring that the TOE security
functions may not be bypassed to allow unauthorized access.
OE.ADMIN supports this policy by ensuring that only competent, trained
administrators have access to the TOE security functions.
Security Objectives Rationale Related to
Assumptions
The security objectives rationale related to assumptions traces the security
objectives for the operational environment back to the assumptions for the TOE’s
operational environment.
Assumption:
A.LOCATE
The hardware appliances will be located within controlled access
facilities and protected from unauthorized physical or logical
modifications. A dedicated port on the TOE is plugged to the out-of-
Version: 2.0 Date: 18 July 2023 Page 24 of 60
band management network used by administrators to connect to the
HTTPS Web GUI of the TOE.
Objectives: OE.PHYSICAL Those responsible for the TOE must ensure that the
TOE is protected from any physical attack.
OE.MANAGEMENT HTTPS access to the Web GUI for management of
the TOE must only be allowed through the
dedicated management network port.
Rationale: The OE.PHYSICAL objective supports this assumption by ensuring the
physical protection of the hardware appliances.
OE.MANAGEMENT objective supports this assumption by ensuring
HTTPS GUI access for administrators is restricted to a dedicated
network management port on the TOE.
Assumption:
A.MANAGE
There will be one or more competent individuals assigned to manage
the TOE and the security of the information it contains.
Objectives: OE.ADMIN Those responsible for the TOE must ensure that the TOE
is delivered, installed, managed, and operated in a
manner which is consistent with IT security. There are
an appropriate number of authorized administrators
trained to maintain the TOE, including its security
policies and practices. Authorized administrators are
non-hostile and follow all administrator guidance.
Rationale: The OE.ADMIN objective supports the assumption by ensuring that all
authorized administrators are qualified and trained to manage the TOE.
Assumption:
A.SINGEN
Information cannot flow among the internal and external networks
unless it passes through the TOE.
Objectives: OE.SINGEN Information cannot flow among the internal and external
networks unless it passes through the TOE.
Rationale: This objective supports the assumption by requiring that the information
flow subject to security policy is made to pass through the TOE.
Version: 2.0 Date: 18 July 2023 Page 25 of 60
5 EXTENDED COMPONENTS DEFINITION
5.1 SECURITY FUNCTIONAL REQUIREMENTS
This section specifies the extended Security Functional Requirements (SFR)s used
in this ST. Three extended SFRs have been created to address additional security
features of the TOE. They are:
a. Anti-Virus Signature Protection (FAV_SIG_EXT.1);
b. Denial of Service (FIP_DOS_EXT.1); and
c. Intrusion Prevention Signature Protection (FIP_SIG_EXT.1).
5.2 CLASS FAV: ANTI-VIRUS
A new class, FAV, was created to address the detection and blocking of malware.
FPT: Protection of the TSF, was used as a model for creating these requirements.
The purpose of this class of requirements is to address the Anti-Virus functionality
provided by the TOE. This new class has a single family – FAV_SIG_EXT.
FAV_SIG_EXT.1 was loosely modelled after FPT_TEE.1: Testing of external
entities.
FAV_SIG_EXT Anti-Virus Signature Protection
Family Behaviour
This family defines the requirements for virus detection and blocking. This family
may be used to specify anti-virus detection and blocking capabilities.
Component Levelling
Figure 3 – FAV_SIG_EXT: Anti-Virus Signature Protection Component Levelling
Management
The following actions could be considered for the management functions in FMT:
a) The management of actions on the information flow when a virus is
detected;
b) The management of actions on virus signatures.
Audit
The following actions should be auditable:
a) Minimal: actions taken on the information flow when virus is detected.
FAV_SIG_EXT.1 Anti-Virus Signature Protection
Hierarchical to: No other components.
Dependencies: No dependencies
FAV_SIG_EXT.1.1 The TSF shall detect and block potential attacks based on similarities
to known virus signatures.
FAV_SIG_EXT.1.2 The TSF shall provide a secure mechanism to update the virus
signatures used by the TSF.
.
FAV_SIG_EXT: Anti-Virus Signature Protection 1
Version: 2.0 Date: 18 July 2023 Page 26 of 60
5.3 CLASS FIP: INTRUSION PREVENTION
A class of FIP requirements was created to address the intrusion prevention
functionality provided by the TOE. FPT: Protection of the TSF, was used as a
model for creating these requirements. The purpose of this class of requirements
is to address the Denial of Service (DoS) and signature-based protection
functionality provided by the TOE. This class of requirements has two families –
FIP_DOS_EXT and FIP_SIG_EXT. FIP_DOS_EXT.1 and FIP_SIG_EXT.1 were
loosely modelled after FPT_TEE.1: Testing of external entities.
FIP_DOS_EXT Denial of Service Prevention
Family Behaviour
This family defines the requirements for detection and blocking of potential Denial
of Service attacks. This family may be used to specify the use of DoS capabilities.
Component Levelling
Figure 4 – FIP_DOS_EXT: Denial of Service Component Levelling
Management
The following actions could be considered for the management functions in FMT:
a. Basic: Configuring of DoS policy.
Audit
The following actions should be auditable:
a. Basic: Detection of a possible DoS attack.
FIP_DOS_EXT.1 Denial of Service
Hierarchical to: No other components.
Dependencies: No dependencies
FIP_DOS_EXT.1.1 The TSF shall be able to recognize and block potential Denial of
Service attacks.
FIP_SIG_EXT Intrusion Prevention Signature
Protection
Family Behaviour
This family defines the requirements for detection and blocking of potential IPS
attacks. This family may be used to specify the IPS policies and signatures.
Component Levelling
Figure 5 – FIP_SIG_EXT: Intrusion Prevention Signature Protection Component Levelling
FIP_DOS_EXT: Denial of Service 1
FIP_SIG_EXT: Intrusion Prevention Signature Protection 1
Version: 2.0 Date: 18 July 2023 Page 27 of 60
Management
The following actions could be considered for the management functions in FMT:
a. Configuring of IPS policies; and
b. Update of IPS signatures.
Audit
The following actions should be auditable:
b. Basic: Detection of a possible attack incident; and
c. Basic: Update of the signature protection profile.
FIP_SIG_EXT.1 Intrusion Prevention Signature Protection
Hierarchical to: No other components.
Dependencies: No dependencies
FIP_SIG_EXT.1.1 The TSF shall detect and block potential attacks based on similarities
to known intrusion attack signatures.
5.4 SECURITY ASSURANCE REQUIREMENTS
This ST does not include extended Security Assurance Requirements.
Version: 2.0 Date: 18 July 2023 Page 28 of 60
6 SECURITY REQUIREMENTS
Section 6 provides security functional and assurance requirements that must be
satisfied by a compliant TOE. These requirements consist of functional
components from Part 2 of the CC, extended requirements, and an Evaluation
Assurance Level (EAL) that contains assurance components from Part 3 of the CC.
6.1 CONVENTIONS
The CC permits four types of operations to be performed on functional
requirements: selection, assignment, refinement, and iteration. These operations,
when performed on requirements that derive from CC Part 2, are identified in this
ST in the following manner:
 Selection: Indicated by surrounding brackets, e.g., [selected item].
 Assignment: Indicated by surrounding brackets and italics, e.g., [assigned
item].
 Refinement: Refined components are identified by using bold for additional
information, or strikeout for deleted text.
 Iteration: Indicated by assigning a number in parenthesis to the end of the
functional component identifier as well as by modifying the functional
component title to distinguish between iterations, e.g., ‘FDP_ACC.1(1),
Subset access control (administrators)’ and ‘FDP_ACC.1(2) Subset access
control (devices)’.
6.2 SECURITY FUNCTIONAL REQUIREMENTS
The security functional requirements for this ST consist of the following
components from Part 2 of the CC and extended components defined in Section 5,
summarized in Table 10.
Class Identifier Name
Security Audit (FAU) FAU_GEN.1 Audit data generation
FAU_GEN.2 User identity association
Cryptographic Support
(FCS)
FCS_CKM.1(1) Cryptographic key generation (Symmetric
Keys)
FCS_CKM.1(2) Cryptographic key generation (RSA Keys)
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
User Data Protection
(FDP)
FDP_IFC.1(1) Subset information flow control (Firewall
SFP)
FDP_IFC.1(2) Subset information flow control (Web
Filtering SFP)
FDP_IFF.1(1) Simple security attributes (Firewall SFP)
FDP_IFF.1(2) Simple security attributes (Web Filtering
SFP)
Identification and
Authentication (FIA)
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
Version: 2.0 Date: 18 July 2023 Page 29 of 60
Class Identifier Name
FIA_UAU.4 Single-use authentication mechanisms
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.2 User identification before any action
Security Management
(FMT)
FMT_MOF.1 Management of security functions
behaviour
FMT_MSA.1(1) Management of security attributes (Firewall
SFP)
FMT_MSA.1(2) Management of security attributes (Web
Filtering SFP)
FMT_MSA.3(1) Static attribute initialisation (Firewall SFP)
FMT_MSA.3(2) Static attribute initialisation (Web Filtering
SFP)
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
Protection of the TSF
(FPT)
FPT_FLS.1 Failure with preservation of secure state
FPT_STM.1 Reliable time stamps
Trusted path/channels
(FTP)
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1 Trusted path
Intrusion Prevention
Requirements (FIP)
FIP_DOS_EXT.1 Denial of service
FIP_SIG_EXT.1 Intrusion Prevention Signature protection
Anti-Virus
Requirements (FAV)
FAV_SIG_EXT.1 Anti-Virus Signature protection
Table 10 – Summary of Security Functional Requirements
Security Audit (FAU)
6.2.1.1 FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [All auditable events listed in Table 11].
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, [information specified in
Table 11].
Version: 2.0 Date: 18 July 2023 Page 30 of 60
Requirement Auditable Events Additional Audit Record Contents
FCS_CKM.1(1)
FCS_CKM.1(2)
Success or failure of the activity
FDP_IFF.1(1)
FDP_IFF.1(2)
Decisions to permit/deny
information flows
FIA_AFL.1 The reaching of the threshold
for the unsuccessful
authentication attempts and
action taken
Identity of the unsuccessfully
authenticated user
FIA_UAU.2 All uses of the authentication
mechanism
FIA_UAU.4 Attempts to reuse
authentication data.
FIA_UAU.5 Decision of the authentication
mechanism
Claimed identity of the user attempting
to authenticate
FIA_UID.2 Unsuccessful use of the user
identification mechanism
Claimed identity of the user using the
identification mechanism
FMT_MOF.1 All modifications in the
behaviour of the functions in
the TSF
The identity of the administrator
performing the function
FMT_MSA.1(1)
FMT_MSA.1(2)
Modification of the security
attributes
The identity of the administrator
performing the function
FMT_MSA.3(1)
FMT_MSA.3(2)
Modification to the default
settings or initial values of
security attributes
FMT_SMF.1 Use of management functions The identity of the administrator
performing the function
FMT_SMR.1 Modifications to the group of
users that are part of a role
User identification of the administrator
performing modification, and the user
whose role is modified
FPT_FLS.1 Failure of a unit within a cluster
FPT_STM.1 Changes to the time The identity of the administrator
performing the operation
FAV_SIG_EXT.1 Actions taken on the
information flow when virus is
detected
FIP_DOS_EXT.1 Detection of a potential Denial
of Service
FIP_SIG_EXT.1 Triggering of a match to a
known signature
Table 11 - Auditable Events
6.2.1.2 FAU_GEN.2 User identity association
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be
able to associate each auditable event with the identity of the user that
caused the event.
Version: 2.0 Date: 18 July 2023 Page 31 of 60
Cryptographic Support (FCS)
6.2.2.1 FCS_CKM.1(1) Cryptographic key generation (symmetric
keys)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(1) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [CTR DRBG (Advanced
Encryption Standard (AES))] and specified cryptographic key sizes
[128, 256 bit] that meet the following: [National Institute of Standards
and Technology (NIST) Special Publication 800-90A].
6.2.2.2 FCS_CKM.1(2) Cryptographic key generation (RSA keys)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(2) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [Rivest Shamir
Adleman (RSA)] and specified cryptographic key sizes [2048, 3072 bit]
that meet the following: [FIPS 186-4].
6.2.2.3 FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [zeroization] that meets the
following: [FIPS 140-2].
6.2.2.4 FCS_COP.1 Cryptographic operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [the cryptographic operations specified in Table 12]
in accordance with a specified cryptographic algorithm [the cryptographic
algorithms specified in Table 12] and cryptographic key sizes
[cryptographic key sizes specified in Table 12] that meet the following:
[standards listed in Table 12].
Version: 2.0 Date: 18 July 2023 Page 32 of 60
Operation Algorithm Key Size or
Digest
(bits)
Standard
Encryption and
Decryption
AES (CBC mode only
or CBC and GCM
modes)
128 and 256
bits
FIPS PUB 197 (AES)
and NIST SP 800-
38A
Cryptographic
Signature
Services
RSA Digital Signature
Algorithm
(RSASSA-PKCS1-v1_5
using SHA-256)
2048, 3072 PKCS #1.5
Elliptic Curve Digital
Signature Algorithm
(ECDSA)
P-256, P-
384, P-521
FIPS 186-4 (Digital
Signature Standard)
Key agreement Key Agreement
Schemes (KAS) and
Key Confirmation
(Diffie-Hellman)
2048 NIST SP800-56A
EC DH P-256, P-
384, P-521
Hashing SHA-1 160 FIPS PUB 180-4
SHA-256 256
SHA-384 384
SHA-512 512
Keyed Hash HMAC-SHA-1 160 key
160 digest
FIPS PUB 198-1
HMAC-SHA-256 256 key
256 digest
HMAC-SHA-384 384 key
384 digest
HMAC-SHA-512 512 key
512 digest
Random Bit
Generation
CTR_DRBG N/A NIST SP800-90A
Table 12 - Cryptographic Operations
User Data Protection (FDP)
6.2.3.1 FDP_IFC.1(1) Subset information flow control (Firewall
SFP)
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1(1) The TSF shall enforce the [Firewall SFP] on:
Version: 2.0 Date: 18 July 2023 Page 33 of 60
[Subjects: users and IT entities3
;
Information: network traffic4
;
Operations: pass information].
6.2.3.2 FDP_IFC.1(2) Subset information flow control (Web
Filtering SFP)
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1(2) The TSF shall enforce the [Web Filtering SFP] on:
[Subjects: users
Information: web pages
Operations: HTTP and HTTPS].
6.2.3.3 FDP_IFF.1(1) Simple security attributes (Firewall SFP)
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1(1) The TSF shall enforce the [Firewall SFP] based on at least the following
types of subject and information security attributes:
[Subjects: users and external entities
Subject security attributes:
 presumed address;
 user identity;
 user group.
Information: network traffic
Information security attributes:
 presumed address of source subject;
 presumed address of destination subject;
 TOE interface on which the traffic arrives and departs;
 service (protocol);
 schedule].
FDP_IFF.1.2(1) The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[Subjects can cause information to flow through the TOE to another
connected network if all the information security attribute values are
unambiguously permitted by the information flow security policy rules,
where such rules may be composed from all possible combinations of the
values of the information flow security attributes].
FDP_IFF.1.3(1) The TSF shall enforce the [none].
FDP_IFF.1.4(1) The TSF shall explicitly authorize an information flow based on the
following rules: [none].
FDP_IFF.1.5(1) The TSF shall explicitly deny an information flow based on the following
rules: [none].
3
Users and IT entities that exchange information via the TOE
4
Any network traffic sent through the TOE from one subject to another
Version: 2.0 Date: 18 July 2023 Page 34 of 60
6.2.3.4 FDP_IFF.1(2) Simple security attributes (Web Filtering
SFP)
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1(2) The TSF shall enforce the [Web Filtering SFP] based on at least the
following types of subject and information security attributes:
[Subjects: users
Subject security attributes:
 optional user ID;
 optional user group.
Information: web pages
Information security attributes:
 URL;
 category assigned by FortiGuard web filtering service based on the
website content;
 local category, if applicable;
 override, if applicable.]
FDP_IFF.1.2(2) The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[
a) The policy for the category to which the URL has been assigned by the
FortiGuard web filtering service is set to ‘allow’;
b) The local category, if used, is set to ‘allow’].
FDP_IFF.1.3(2) The TSF shall enforce the [no additional rules].
FDP_IFF.1.4(2) The TSF shall explicitly authorize an information flow based on the
following rules: [
a) An override has been set for the URL].
FDP_IFF.1.5(2) The TSF shall explicitly deny an information flow based on the following
rules: [none].
Application Note: The FortiGuard web filtering service assigns all websites to a category
based on content. Those not assigned to other categories are assigned to the ‘Unrated’
category. For example, the cached content classification indicates that the site caches
content, but provides no indication of the content type.
Identification and Authentication (FIA)
6.2.4.1 FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1 The TSF shall detect when an administrator configurable positive integer
within [1 and 10] unsuccessful authentication attempts occur related to
[authorized TOE administrator access].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been [surpassed], the TSF shall [lock out the application TCP session for a
configurable period of time].
Application Note: This feature is not applicable to console login or public key authentication.
Version: 2.0 Date: 18 July 2023 Page 35 of 60
6.2.4.2 FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: [
a) identity;
b) role;
c) authentication data].
6.2.4.3 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
6.2.4.4 FIA_UAU.4 Single-use authentication mechanisms
Hierarchical to: No other components
Dependencies: No dependencies
FIA_UAU.4.1 The TSF shall prevent the reuse of authentication data related to [the
FortiToken single use authentication mechanism].
6.2.4.5 FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide [password, one time passcode, pre-shared key,
public key, and X.509 certificate based authentication mechanisms] to
support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[the following rules:
a) administrators authenticate to the console, CLI or web interface via
username and password;
b) administrators may authenticate via username and password or RSA
public key for remote SSH connections;
c) users authenticate to the TOE using a username and password;
d) x.509 certificates are used to authenticate IPsec VPN peers; and
e) pre-shared keys are used to authenticate IPsec VPN peers.
6.2.4.6 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies.
FIA_UID.2.1 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Security Management (FMT)
6.2.5.1 FMT_MOF.1 Management of security functions behaviour
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Version: 2.0 Date: 18 July 2023 Page 36 of 60
FMT_MOF.1.1 The TSF shall restrict the ability to [enable, disable, modify the
behaviour of] the functions [
a) Denial of Service (DOS) detection policy implementation; and
b) Signature based protection policy implementation]
to [an authorized administrator].
6.2.5.2 FMT_MSA.1(1) Management of security attributes
(Firewall SFP)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1(1) The TSF shall enforce the [Firewall SFP] to restrict the ability to [delete
attributes from a rule, modify attributes in a rule, add attributes to a
rule] the security attributes [user identity user group, source address,
destination address, service, schedule] to [the authorized
administrator].
6.2.5.3 FMT_MSA.1(2) Management of security attributes (Web
Filtering SFP)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1(2) The TSF shall enforce the [Web Filtering SFP] to restrict the ability to
[query, modify, delete] the security attributes [user ID, user group,
URL, category, and override setting] to [the authorized administrator].
6.2.5.4 FMT_MSA.3(1) Static attribute initialisation (Firewall SFP)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1(1) The TSF shall enforce the [Firewall SFP] to provide [restrictive] default
values for information flow security attributes that are used to enforce
the SFP.
FMT_MSA.3.2(1) The TSF shall allow the [authorized administrator] to specify
alternative initial values to override the default values when an object or
information is created.
Application Note: The default values for the information flow control security attributes
appearing in FDP_IFF.1(1) are intended to be restrictive in the sense that both inbound
and outbound information is denied by the TOE until the default values are modified by an
authorized administrator.
6.2.5.5 FMT_MSA.3(2) Static attribute initialisation (Web Filtering
SFP)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Version: 2.0 Date: 18 July 2023 Page 37 of 60
FMT_MSA.3.1(2) The TSF shall enforce the [Web Filtering SFP] to provide [restrictive]
default values for information flow security attributes that are used to
enforce the SFP.
FMT_MSA.3.2(2) The TSF shall allow the [authorized administrator] to specify
alternative initial values to override the default values when an object or
information is created.
6.2.5.6 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [
a) administer firewall policy rules;
b) administer web filtering functionality;
c) administer VPN rules;
d) administer security audit functionality;
e) administer user account information;
f) administer authentication mechanisms and authentication failure
handling policy;
g) administer DoS and signature based protection policy implementation].
6.2.5.7 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [administrator].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Protection of the TSF (FPT)
6.2.6.1 FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur: [failure of a unit in a FortiGate cluster is detected].
Application Note: The FPT_FLS.1 requirement is only implemented in the High
Availability configuration of the TOE.
6.2.6.2 FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Trusted Path/Channels (FTP)
6.2.7.1 FTP_ITC.1 Inter-TSF trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another
trusted IT product that is logically distinct from other communication
Version: 2.0 Date: 18 July 2023 Page 38 of 60
channels and provides assured identification of its end points and protection
of the channel data from modification or disclosure.
FTP_ITC.1.2 The TSF shall permit [the TSF, another trusted IT product] to initiate
communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [High
Availability Cluster communication, IPsec VPN services].
6.2.7.2 FTP_TRP.1 Trusted path
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [remote]
users that is logically distinct from other communication paths and provides
assured identification of its end points and protection of the communicated
data from [modification, disclosure].
FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the
trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [remote
administration].
Intrusion Prevention (FIP) (EXT)
6.2.8.1 FIP_DOS_EXT.1 Denial of Service
Hierarchical to: No other components.
Dependencies: No dependencies.
FIP_DOS_EXT.1.1 The TSF shall be able to recognize and block potential Denial of
Service attacks.
6.2.8.2 FIP_SIG_EXT.1 Intrusion Prevention Signature Protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FIP_SIG_EXT.1.1 The TSF shall detect and block potential attacks based on similarities
to known intrusion attack signatures.
FIP_SIG_EXT.1.2 The TSF shall provide a secure mechanism to update the intrusion
attack signatures used by the TSF.
Anti-Virus Requirements (FAV) (EXT)
6.2.9.1 FAV_SIG_EXT.1 Anti-Virus Signature Protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FAV_SIG_EXT.1.1 The TSF shall detect and block potential attacks based on similarities
to known virus signatures.
FAV_SIG_EXT.1.2 The TSF shall provide a secure mechanism to update the virus
signatures used by the TSF.
Application Note: Virus signature updates consist of updates to both the virus signature
database and the processing engine for the detection of virus attacks. The TOE provides
specific guidance to administrators noting that in the evaluated configuration of the TOE,
only the virus signature database updates may be applied to the TOE.
Version: 2.0 Date: 18 July 2023 Page 39 of 60
6.3 SECURITY ASSURANCE REQUIREMENTS
The assurance requirements are summarized in the following table.
Assurance Class
Assurance Components
Identifier Name
Development (ADV) ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
Guidance Documents
(AGD)
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Life-Cycle Support
(ALC)
ALC_CMC.4
Production support, acceptance procedures
and automation
ALC_CMS.4 Problem tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_FLR.3 Systematic flaw remediation
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
Security Target
Evaluation (ASE)
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
Tests (ATE) ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing
Vulnerability
Assessment (AVA)
AVA_VAN.3 Focused vulnerability analysis
Table 13 – Security Assurance Requirements
6.4 SECURITY REQUIREMENTS RATIONALE
Security Functional Requirements Rationale
The following Table provides a mapping between the SFRs and Security
Objectives.
Version: 2.0 Date: 18 July 2023 Page 40 of 60
O.ACCESS
O.ADMIN
O.AUDIT
O.ENCRYPT
O.IDENTAUTH
O.MEDIATE
O.PROTECT
O.REUSE
O.TIME
O.VIRUS
FAU_GEN.1 X
FAU_GEN.2 X
FCS_CKM.1(1) X
FCS_CKM.1(2) X
FCS_CKM.4 X
FCS_COP.1 X
FDP_IFC.1(1) X
FDP_IFC.1(2) X
FDP_IFF.1(1) X
FDP_IFF.1(2) X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_UAU.2 X X X
FIA_UAU.4 X X
FIA_UAU.5 X
FIA_UID.2 X X
FMT_MOF.1 X X X
FMT_MSA.1(1) X X X
FMT_MSA.1(2) X X X
FMT_MSA.3(1) X X
FMT_MSA.3(2) X X
FMT_SMF.1 X X
FMT_SMR.1 X X
FPT_FLS.1 X
FPT_STM.1 X
FTP_ITC.1 X
FTP_TRP.1 X
FIP_DOS_EXT.1 X X
FIP_SIG_EXT.1 X X
FAV_SIG_EXT.1 X X
Table 14 – Mapping of SFRs to Security Objectives
Version: 2.0 Date: 18 July 2023 Page 41 of 60
SFR Rationale Related to Security Objectives
The following rationale traces each SFR back to the Security Objectives for the
TOE.
Objective:
O.ACCESS
The TOE must allow authorized users to access only appropriate TOE
functions and data.
Security
Functional
Requirements:
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
FMT_MOF.1 Management of security functions behaviour
FMT_MSA.1(1) Management of security attributes (Firewall SFP)
FMT_MSA.1(2) Management of security attributes (Web Filtering SFP)
Rationale: FIA_UID.2 and FIA_UAU.2 ensure that users are identified and
authenticated prior to being allowed access to TOE security management
functionality.
FMT_MOF.1 ensures that only authorized administrators have access to IPS
security management functions. FMT_MSA.1(1) and FMT_MSA.1(2) ensure
that only authorized administrators have access to the security attributes
associated with the firewall and web filtering security functional policies.
Objective:
O.ADMIN
The TOE must provide functionality that enables an authorized
administrator to manage TOE security functions, and must ensure that only
authorized administrators are able to access such functionality.
Security
Functional
Requirements:
FMT_MOF.1 Management of security functions behaviour
FMT_MSA.1(1) Management of security attributes (Firewall SFP)
FMT_MSA.1(2) Management of security attributes (Web Filtering SFP)
FMT_MSA.3(1) Static attribute initialisation (Firewall SFP)
FMT_MSA.3(2) Static attribute initialisation (Web Filtering SFP)
FMT_SMF.1 Specification of Management Functions
Rationale: FMT_MOF.1 meets this objective by providing functionality to manage the
behaviour of the Denial of Service and signature based protection features
of the TOE.
FMT_MSA.1(1) and FMT_MSA.1(2) meet the objective by providing the
functionality to manage the parameters associated with the firewall and
web filtering security functional policies.
FMT_MSA.3(1) and FMT_MSA.3(2) meet the objective by providing the
initial values required to manage the firewall and web filtering security
functional policies.
FMT_SMF.1 meets the objective by providing the management functions
supporting the specific security management claims.
Objective:
O.AUDIT
The TOE must provide user accountability for information flows through the
TOE and for authorized administrator use of security functions by providing
a means to record an audit trail of security-related events, with accurate
dates and times.
Security
Functional
Requirements:
FAU_GEN.1 Audit data generation
FAU_GEN.2 User identity association
Rationale: FAU_GEN.1 supports the objective by detailing the set of events that the
TOE must be capable of recording, ensuring that any security relevant
event that takes place in the TOE is audited.
Version: 2.0 Date: 18 July 2023 Page 42 of 60
FAU_GEN.2 supports the objective by ensuring that the audit records
associate a user identity with the auditable event.
Objective:
O.ENCRYPT
The TOE must protect the confidentiality and integrity of data passed
between itself and an authorized administrator, between itself and VPN
peers, or between TOE devices using cryptographic functions.
Security
Functional
Requirements:
FCS_CKM.1(1) Cryptographic key generation (Symmetric keys)
FCS_CKM.1(2) Cryptographic key generation (RSA keys)
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1 Trusted path
Rationale: FCS_CKM.1(1), FCS_CKM.1(2), FCS_CKM.4, and FCS_COP.1 support the
objective by providing the cryptographic functionality required to support
trusted links.
FTP_ITC.1 and FTP_TRP.1 support the objective by specifying the use of
cryptography between trusted VPN clients and peer devices, and between
the TOE and the remote administrator.
Objective:
O.IDENTAUTH
The TOE must be able to identify and authenticate authorized users prior to
allowing access to TOE security management functions or, if required, to a
connected network.
Security
Functional
Requirements:
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UAU.4 Single-use authentication mechanisms
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.2 User identification before any action
FMT_SMR.1 Security roles
Rationale: FIA_ATD.1 supports this objective by ensuring that the data required to
identify and authenticate users is maintained by the TOE.
FIA_UID.2 and FIA_UAU.2 ensure that users are identified and
authenticated prior to being granted access to TOE security management
functions, or to a connected network.
FIA_UAU.4 supports the objective by providing a single use authentication
mechanism. FIA_UAU.5 provides multiple possible authentication
mechanisms that may be used to support the objective.
FMT_SMR.1 supports the objective by providing roles which are used to
provide users access to TOE security functionality.
Objective:
O.MEDIATE
The TOE must mediate the flow of all information between clients and
servers located on internal and external networks governed by the TOE.
Security
Functional
Requirements:
FDP_IFC.1(1) Subset information flow control (Firewall SFP)
FDP_IFC.1(2) Subset information flow control (Web Filtering SFP)
FDP_IFF.1(1) Simple security attributes (Firewall SFP)
FDP_IFF.1(2) Simple security attributes (Web Filtering SFP)
FAV_SIG_EXT.1 Anti-Virus Signature Protection
FIP_DOS_EXT.1 Denial of Service Prevention
Version: 2.0 Date: 18 July 2023 Page 43 of 60
FIP_SIG_EXT.1 Intrusion Prevention Signature Protection
Rationale: FDP_IFC.1(1) and FDP_IFF.1(1) support the objective by detailing how the
TOE mediates the flow of information for the firewall policy.
FDP_IFC.1(2) and FDP_IFF.1(2) support the objective by detailing how the
TOE mediates the flow of information for the web filtering policy.
FIP_DOS_EXT.1 and FIP_SIG_EXT.1 support the objective by detecting and
preventing denial of service attacks and attacks with known signatures
present in the information flow.
FAV_SIG_EXT.1 supports the objective by taking specific actions when a
virus is detected in the flow of information.
Objective:
O.PROTECT
The TOE must protect itself and the designated network against attempts
by unauthorized users to bypass, deactivate, or tamper with TOE security
functions in such a way as to cause unauthorized access to its functions
and data, or to deny access to legitimate users.
Security
Functional
Requirements:
FIA_AFL.1 Authentication failure handling
FMT_MOF.1 Management of security functions behaviour
FMT_MSA.1(1) Management of security attributes (Firewall SFP)
FMT_MSA.1(2) Management of security attributes (Web Filtering SFP)
FMT_MSA.3(1) Static attribute initialisation (Firewall SFP)
FMT_MSA.3(2) Static attribute initialisation (Web Filtering SFP)
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FPT_FLS.1 Failure with preservation of secure state
FIP_DOS_EXT.1 Denial of service
FIP_SIG_EXT.1 Intrusion Prevention Signature Protection
Rationale: The security management SFRs, FMT_MOF.1, FMT_MSA.1(1),
FMT_MSA.1(2), FMT_MSA.3(1), FMT_MSA.3(2), FMT_SMF.1 and
FMT_SMR.1 support the objective by ensuring that access to TOE security
functions is limited to authorized users.
FIA_AFL.1 supports the objective by ensuring that unauthorized users are
locked out following a configurable number of unsuccessful authentication
attempts, thereby thwarting a brute force attack on the TOE.
FPT_FLS.1 supports the objective by ensuring that the TOE, in a high
availability configuration, remains secure and operational in the case of a
unit failure.
FIP_DOS_EXT.1 and FIP_SIG_EXT.1 support the objective by preventing
denial of service attacks and attacks identifiable by their unique signatures.
Objective:
O.REUSE
The TOE must provide a means to prevent the reuse of authentication data
for users attempting to authenticate to the TOE from a connected network.
Security
Functional
Requirements:
FIA_UAU.2 User authentication before any action
FIA_UAU.4 Single-use authentication mechanisms
Rationale: FIA_UAU.2 and FIA_UAU.4 support this objective by providing a single use
authentication mechanism and requiring users to be authenticated prior to
gaining access.
Version: 2.0 Date: 18 July 2023 Page 44 of 60
Objective:
O.TIME
The TOE shall provide reliable time stamps.
Security
Functional
Requirements:
FPT_STM.1 Reliable time stamps
Rationale: FPT_STM.1 supports this objective by requiring that the TOE be able to
provide reliable time stamps.
Objective:
O.VIRUS
The TOE will detect and block viruses contained within an information flow
which arrives at any of the TOE network interfaces.
Security
Functional
Requirements:
FAV_SIG_EXT.1 Anti-Virus Signature Protection
Rationale: FAV_SIG_EXT.1 supports this objective by ensuring that the TOE can
detect and block information that may contain a virus.
Dependency Rationale
Table 15 identifies the Security Functional Requirements from Part 2 of the CC and
their associated dependencies. It also indicates whether the ST explicitly
addresses each dependency.
SFR Dependency Dependency Satisfied Rationale
FAU_GEN.1 FPT_STM.1 
FAU_GEN.2 FAU_GEN.1 
FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FCS_CKM.1(1) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1.
FCS_CKM.4 
FCS_CKM.1(2) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1.
FCS_CKM.4 
FCS_CKM.4 FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1

FCS_COP.1 FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
 Satisfied by FCS_CKM.1.
FCS_CKM.4 
FDP_IFC.1(1) FDP_IFF.1  Satisfied by FDP_IFF.1(1).
FDP_IFC.1(2) FDP_IFF.1  Satisfied by FDP_IFF.1(2).
FDP_IFF.1(1) FDP_IFC.1  Satisfied by FDP_IFC.1(1).
FMT_MSA.3  Satisfied by FMT_MSA.3(1).
Version: 2.0 Date: 18 July 2023 Page 45 of 60
SFR Dependency Dependency Satisfied Rationale
FDP_IFF.1(2) FDP_IFC.1  Satisfied by FDP_IFC.1(2).
FMT_MSA.3  Satisfied by FMT_MSA.3(2).
FIA_AFL.1 FIA_UAU.1  FIA_UAU.2 is hierarchical to
FIA_UAU.1; this dependency
has been satisfied.
FIA_ATD.1 None N/A
FIA_UAU.2 FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FIA_UAU.4 None N/A
FIA_UAU.5 None N/A
FIA_UID.2 None N/A
FMT_MOF.1 FMT_SMR.1 
FMT_SMF.1 
FMT_MSA.1(1) FDP_ACC.1 or
FDP_IFC.1
 Satisfied by FDP_IFC.1(1).
FMT_SMR.1 
FMT_SMF.1 
FMT_MSA.1(2) FDP_ACC.1 or
FDP_IFC.1
 Satisfied by FDP_IFC.1(2).
FMT_SMR.1 
FMT_SMF.1 
FMT_MSA.3(1) FMT_MSA.1  Satisfied by FMT_MSA.1(1).
FMT_SMR.1 
FMT_MSA.3(2) FMT_MSA.1  Satisfied by FMT_MSA.1(2).
FMT_SMR.1 
FMT_SMF.1 None N/A
FMT_SMR.1 FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FPT_FLS.1 None N/A
FTP_ITC.1 None N/A
FTP_TRP.1 None N/A
FAV_SIG_EXT.1 None N/A
FIP_DOS_EXT.1 None N/A
FIP_SIG_EXT.1 None N/A
Table 15 – Functional Requirement Dependencies
Version: 2.0 Date: 18 July 2023 Page 46 of 60
Security Assurance Requirements Rationale
The TOE assurance requirements for this ST consist of the requirements
corresponding to the EAL 4 level of assurance, as defined in the CC Part 3,
augmented by the inclusion of Systematic Flaw Remediation (ALC_FLR.3). EAL 4
was chosen for competitive reasons. The developer is claiming the ALC_FLR.3
augmentation since there are a number of areas where current practices and
procedures exceed the minimum requirements for EAL 4.
Version: 2.0 Date: 18 July 2023 Page 47 of 60
7 TOE SUMMARY SPECIFICATION
This section provides a description of the security functions and assurance
measures of the TOE that meet the TOE security requirements.
7.1 SECURITY AUDIT
The TOE creates audit records for administrative events, potential policy violations
and information flow decisions. The TOE records the identity of the administrator
or user who caused the event for which the audit record is created. The TOE
applies timestamps to auditable events as they occur.
The administrator can review the audit records. The audit records are stored
locally, using memory, a hard disk or a FLASH memory card depending on the
model. Logs may be read using the CLI or the web interface on the FortiGate unit.
This functionality is provided by default to the primary administrator account, and
must be specifically granted to any administrator account that may be created.
If the TOE is operating as part of an Active-Active HA cluster, the HA master logs
all administrative events for the cluster. The status of each node in a clustered
TOE is identified by a heartbeat. When the heartbeat response is not received
from a slave node, the master node no longer routes packets to the failed node. If
the master fails, an existing node in the cluster will be promoted to become the
master node. The HA master also logs all potential policy violations and
information flow decisions that it processes. HA slaves log all potential policy
violations and information flow decisions that they process.
TOE Security Functional Requirements addressed: FAU_GEN.1, FAU_GEN.2.
7.2 CRYPTOGRAPHIC SUPPORT
The FortiOS cryptographic module is used in support of the TLS, SSH, and IPsec
protocols. Asymmetric keys are also generated in support of TLS functionality.
Models deployed with the FortiASIC CP9, CP9lite or CP9Xlite rely on that Content
Processor as the source for entropy. All virtual models (VMs) rely on the Araneus
Alea II hardware token as their entropy source. The entropy source for each
hardware model can be found in Table 18 (hardware models) and Table 19 (virtual
models).
Cryptographic key destruction meets the key zeroization requirements of Key
Management Security Level 1 from FIPS PUB 140-2. The TOE only stores keys in
memory, either in Synchronous Dynamic Random Access Memory (SDRAM) or
Flash Random Access Memory (RAM). Keys are destroyed by overwriting the key
storage area with zeros.
Cryptographic operations are performed in accordance with the detail provided in
Table 12.
The vendor affirms that no source code changes were made to the cryptographic
module prior to recompilation into the TOE software.
TOE Security Functional Requirements addressed: FCS_CKM.1(1), FCS_CKM.1(2),
FCS_CKM.4, FCS_COP.1.
7.3 USER DATA PROTECTION
The TOE operates in accordance with the following information flow security
functional policies:
Version: 2.0 Date: 18 July 2023 Page 48 of 60
a. The Firewall SFP allows authenticated and unauthenticated users to pass
information through the TOE, with firewall mediation according to the
firewall rules defined by an authorized administrator. Separate policies may
be defined for unauthenticated and authenticated users;
b. The Web Filtering SFP allows users to access only those URLs which are
allowed.
The security functional policies are implemented as firewall rules. The rules that
implement the Firewall SFP have restrictive default values and by default no
information is allowed to flow. The Web Filtering SFP has permissive default
values, and does not block URLs until specifically identified. Modification of the
rules is restricted to an authorized administrator, and an authorized administrator
may also specify alternative initial values to override the default values.
The TOE mediates all information flows which pass through it. For information to
pass through the TOE, it must match one of an authorized administrator specified
firewall rules which permit the information flow.
The TOE ensures that all information flows provided to the TOE by external
entities for transfer to other entities are subjected to the defined firewall rules and
conform to them before they are allowed to proceed toward the destination entity.
The TSF immediately enforces revocation of a user's permission to use the
information flow and also immediately enforces changes to the information flow
policy rules when applied. The TOE also immediately enforces the disabling of a
service which was available to an unauthenticated user.
The TOE follows a sequence of ordered steps in order to decide whether or not a
requested information flow is allowed to proceed. The very first processing step
performed on incoming information is an inspection for IPS anomalies which target
the TOE directly. Examples of IPS anomalies include syn floods, ping of death,
source routing and port scans. If the incoming information flow is not blocked by
the inspection for IPS anomalies, it is next processed against the firewall policy
rules and authentication requirements. If the incoming information flow is allowed
by the firewall policy rules (using the first match algorithm) and if any required
authentication has been completed successfully, the incoming information flow
may be subject to additional restrictions based on any Protection Profile which is
associated with the firewall policy rule which allowed the information flow.
Protection Profiles are used to define additional information flow restrictions which
may be based on any or all of the following types of information:
 Scheduling
 SMTP commands
 SMTP Multi-Purpose Internet Mail Extensions (MIME) types
 FTP subcommands
 HTTP request methods
 Virus signatures
 IPS signature matching
Only an authorized administrator may create, modify or delete a Protection Profile.
Additionally, only an authorized administrator may associate a Protection Profile
with a firewall policy rule.
Version: 2.0 Date: 18 July 2023 Page 49 of 60
If the request is an HTTP or HTTPS, the URL may be checked against the
FortiGuard Web Filtering Policy. FortiGuard Web Filtering is made up of an external
service which provides category information for any requested website, and an
internal policy that applies that information. When FortiGuard Web Filter is
enabled in a web filter profile, the setting is applied to all firewall policies that use
this profile. When a request for a web page appears in traffic controlled by one of
these firewall policies, the URL is sent to the nearest FortiGuard server. The URL
category is returned. If the category is blocked, the TOE provides a replacement
message in place of the requested page. If the category is not blocked, the page
request is sent to the requested URL as normal.
The specific steps used by the TOE to process incoming information flows and
enforce its security policy are summarized below:
1. Local IPS Anomaly protection (kernel level);
2. First matched policy must explicitly allow traffic to flow;
3. If configured, successful authentication is required for traffic to flow; and
4. Protection Profile services (if explicitly enabled):
a. Scheduling: If scheduling is enabled, time period must be explicitly
allowed,
b. SMTP Commands: All SMTP commands permitted unless explicitly
denied,
c. MIME Types: All MIME types permitted unless explicitly denied,
d. FTP Sub-Commands: All FTP sub-commands permitted unless
explicitly denied,
e. HTTP Request Methods: All HTTP request methods permitted unless
explicitly denied,
f. FortiGuard Web Filter: All URL requests are checked against the web
filter policy to determine if they are allowed or blocked.
g. Virus protection: If content is matched against an Anti-Virus (AV)
signature, the configured action is performed, and
h. IPS Signature matching: If the nature of the connection or content is
matched against an IPS signature, the configured action is
performed.
It must be noted that traffic is only passed to the next enforcement method if
previous enforcement methods explicitly allow the traffic.
After all security policy enforcement is performed and no further security scrutiny
is required, the packet data is forwarded to the network host as determined by the
configuration of the egress interface and/or static route.
TOE Security Functional Requirements addressed: FDP_IFC.1(1), FDP_IFC.1(2),
FDP_IFF.1(1), FDP_IFF.1(2).
7.4 IDENTIFICATION AND AUTHENTICATION
In order to protect the TOE data and services, the TOE requires identification and
authentication for all administrative access and some network user access to
specific services when required by firewall policies. The TOE maintains identity,
role/authorization and authentication data to support this functionality.
Identification and authentication are always enforced on the serial interface (local
Version: 2.0 Date: 18 July 2023 Page 50 of 60
console). On the network interfaces identification and authentication is enforced
for all administrator access, specific services, and VPN users. For local
administrators and users, the identification and authentication mechanism are a
username and password combination. Local users and administrators are
presented with a system screen (configurable by an authorized administrator)
prior to authentication. For remote SSH administration, a username and password
combination or SSH-RSA public key authentication are used. For remote
administration access to the Web-Manager GUI (HTTPS) or the CLI (SSH), a
FortiToken one-time password generator can be configured and required for
authentication. VPN peers authenticate using pre-shared keys or certificates for
IPsec VPN services. The accounts are created by an authorized administrator over
the serial or network interfaces.
All certificate-based authentication is performed against a CA certificate held
inside a trust store maintained by the TOE.
After a configurable number of unsuccessful authentication attempts,
administrators are prevented from attempting to login from the same IP session
for a preconfigured amount of time.
TOE Security Functional Requirements addressed: FIA_AFL.1, FIA_ATD.1,
FIA_UAU.2, FIA_UAU.4, FIA_UAU.5, FIA_UID.2.
7.5 SECURITY MANAGEMENT
Appropriately authorized administrators may manage security function behaviour,
users, IPS policies and information flow policies. The TOE immediately enforces
the revocation of a user from an administrative access profile.
The TOE provides a web-based GUI and a local Console CLI for administrators to
manage all of the security functions.
An administrator account consists of an administrator’s identification and
authentication information, and access profile. The access profile is a set of
permissions that determine which functions the administrator is allowed to access.
(The term ‘role’ is used in FMT_SMR.1; however, the TOE uses the term access
profile in its administration.) For any function, a profile may allow either read only
or read-write access. When an administrator has read-only access to a feature,
the administrator can access the web-based manager page for that feature but
cannot make changes to the configuration. Similar permissions are enforced for
the CLI.
Each FortiGate unit (and the virtual model) comes with a default administrator
account with all permissions, which may not be deleted. The term ‘authorized
administrator’ is used throughout this ST to describe an administrator given the
appropriate permission to perform tasks as required.
TOE Security Functional Requirements addressed: FMT_MOF.1, FMT_MSA.1(1),
FMT_MSA.1(2), FMT_MSA.3(1), FMT_MSA.3(2), FMT_SMF.1, FMT_SMR.1.
7.6 PROTECTION OF THE TSF
The HA feature provides failover protection capability which includes configuration
synchronization. The FortiGate units that make up the HA cluster exchange
configuration information using a proprietary protocol (FortiGate Clustering
Protocol (FGCP)). Before any information is exchanged, members of a HA cluster
authenticate using information built into the FortiGate unit at the time of
manufacture. Configuration information is exchanged every time the configuration
Version: 2.0 Date: 18 July 2023 Page 51 of 60
of the master node in a HA cluster is updated. In this way, the slave or passive
nodes in a cluster are prepared to assume the role of master node should the
master node fail.
Time is provided by the TSF and can only be changed by an authorized
administrator. The appliances include a hardware clock which is used to generate
reliable time stamps which in turn are used for audit records and to provide
scheduling features for flow control policies. The hardware clock does not rely
upon any external factors in order to function correctly. The time setting of the
hardware clock may only be modified by an authorized administrator and all such
modifications are recorded in the audit log. For the virtual device, time information
is provided to the TOE from the underlying hardware.
TOE Security Functional Requirements addressed: FPT_FLS.1, FPT_STM.1.
7.7 TRUSTED PATH / CHANNELS
The TOE provides trusted paths and trusted channels, protected by encryption to
guard against disclosure and protected by cryptographic signature to detect
modifications. The trusted paths and trusted channels are logically distinct from
other communication paths and provide assured identification of their end points.
The trusted paths are used to protect remote administrator authentication and all
remote administrator actions.
The VPN functionality supports IPsec tunnel mode. Authentication for IPsec
services may be performed using Internet Key Exchange (IKE) pre-shared key or
IKE RSA key. The IPsec VPN functionality is implemented through the
Encapsulated Security Payload (ESP) protocol. TOE devices support IKEv1 and
IKEv2.
In the evaluated configuration, IKE protocols support the use of Diffie-Hellman
(DH) group14 (with 2048 MODP). Certificate based authentication may be used,
as well as pre-shared key based authentication for IPsec peer connections.
Remote clients connect to the FortiGate unit that authenticates network users as
members of a user group. When the network user initiates a VPN connection with
the FortiGate unit they must use an approved authentication method with the TOE
such as X.509 certificates, username & password, or two factor authentication
such as with FortiToken. The FortiGate unit then assigns the client a virtual IP
address from a range of reserved addresses. The client uses the assigned IP
address as its source address for the duration of the connection. After the tunnel
has been established, the user is granted access to the network behind the
FortiGate unit.
The Network Web-Based GUI uses the HTTPS protocol for secure administrator
communications. With respect to the TOE implementation of HTTPS, TLS version
1.1 (RFC 4346) and TLS 1.2 (RFC 5246) are used to encrypt and authenticate
administration sessions between the remote browser and TOE. When a connection
is first established, the server presents the public key certificate to the connecting
web browser. The administrator can examine the certificate to validate the identity
of the TOE and then choose to continue with the connection if the certificate
conforms to the expected values. Local administrator account credentials can be
used to successfully authenticate to the TOE via the Network Web-Based GUI.
SSH is used to protect remote connections to the CLI. Administrators use
password based or SSH-RSA public key authentication.
The trusted channels provide communication between the TOE and other TOE
devices in support of the HA cluster configuration. This channel is logically distinct
Version: 2.0 Date: 18 July 2023 Page 52 of 60
from other communication channels. The channel is encrypted with AES-128. This
ensures that the cluster password and changes to the cluster configuration are not
exposed allowing an attacker to sniff HA packets to get cluster information.
TOE Security Functional Requirements addressed: FTP_ITC.1 and FTP_TRP.1
7.8 INTRUSION PREVENTION
The TOE provides an Intrusion Prevention System that examines network traffic
arriving on its interfaces for evidence of intrusion attempts.
Ingress packets received on a FortiGate interface are passed to the Denial of
Service sensors, which determine if it is a valid information request or not.
Detection of any potential attack is recorded in the IPS or packet logs. If the
packet can pass based on the information flow policy (based on the Fortinet
Protection Profile), it is examined against IPS signatures known to indicate
potential attacks. If evidence of an attack is found, the TOE records the event in
the IPS or packet logs. These logs are made available only to authorized
administrators and is provided in a manner suitable for the administrators to
interpret the information.
TOE Security Functional Requirements addressed: FIP_DOS_EXT.1,
FIP_SIG_EXT.1.
7.9 ANTI-VIRUS
The TOE detects and prevents virus attacks contained within information flows
which arrive at any of its network interfaces. An authorized administrator may
configure the TOE to block and or quarantine a virus which is detected in an
information flow. The TOE may also be configured to monitor the information flow
and make a record of any virus found, but perform no other action. The TOE
provides a secure mechanism for the update of virus signatures used by the TSF.
TOE Security Functional Requirements addressed: FAV_SIG_EXT.1
Version: 2.0 Date: 18 July 2023 Page 53 of 60
8 TERMINOLOGY AND ACRONYMS
8.1 TERMINOLOGY
The following terminology is used in this ST:
Term Description
Firewall Rules Firewall rules are configuration parameters set by an
authorized administrator that allow or deny data flow through
the TOE. These rules may optionally include the use of a
firewall Protection Profile that enforces AV and IPS
configuration parameters.
FortiGate Clustering
Protocol
A proprietary protocol used to exchange data to configure and
synchronize the FortiGate units that form a High Availability
cluster.
Local Console A management console (may be a computer workstation or
VT100 type terminal) connected directly to the TOE. It is
located in the same physical location as the TOE and therefore
is provided with the same physical protection as is provided
for the TOE.
Network Management
Station
A computer located remotely from the TOE but which is able
to establish a network connection to the TOE. The Network
Management Station falls outside the TOE Boundary.
Presumed Address The TOE can make no claim as to the real address of any
source or destination subject; the TOE can only suppose that
these addresses are accurate. Therefore, a ‘presumed
address’ is used to identify source and destination addresses.
Protection Profile Both the Common Criteria and Fortinet use the term
Protection Profile. Within this ST, the context generally makes
it clear which usage is appropriate. However, for clarity, the
CC usage is generally noted by the abbreviation PP while the
Fortinet usage is always denoted by spelling out the complete
term.
Table 16 – Terminology
Version: 2.0 Date: 18 July 2023 Page 54 of 60
8.2 ACRONYMS
The following acronyms are used in this ST:
Acronym Definition
AES Advanced Encryption Standard
ASIC Application-specific Integrated Circuit
AV Anti-Virus
CA Certificate Authority
CAVP Cryptographic Algorithm Validation Program
CBC Cipher-block Chaining
CC Common Criteria
CLI Command Line Interface
CM Configuration Management
CMVP Cryptographic Module Validation Program
CRL Certificate Revocation List
CTR Counter-mode
DH Diffie-Hellman
DoS Denial of Service
EAL Evaluation Assurance Level
ESP Encapsulating Security Protocol
FGCP FortiGate Clustering Protocol
FIPS Federal Information Processing Standards
FTP File Transfer Protocol
GUI Graphical User Interface
HA High Availability
HMAC Keyed Hash Message Authentication Code
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IDS Intrusion Detection System
IFC Integer Factorization Cryptography
IKE Internet Key Exchange
IMAP Internet Message Access Protocol
IP Internet Protocol
IPS Intrusion Prevention System
IPsec Internet Protocol Security
Ipv4, Ipv6 Internet Protocol version 4, Internet Protocol version 6
IT Information Technology
MIME Multi-Purpose Internet Mail Extensions
MODP Modular Exponential
NAT Network Address Translation
NGFW Next Generation Firewall
NIST National Institute of Standards and Technology
OID Object Identifier
PKCS Public-Key Cryptography Standards
Version: 2.0 Date: 18 July 2023 Page 55 of 60
Acronym Definition
PoE Power over Ethernet
POP3 Post-Office Protocol Version 3
PP Common Criteria Protection Profile
PUB Publication
RAM Random Access Memory
RFC Request for Comments
ROBO Remote Office and Branch Office
RSA Rivest, Shamir and Adleman
RSASSA-PKCS1-v1_5 RSA Signature Scheme with Appendix PKCS1
SA Security Association
SDRAM Synchronous Dynamic Random Access Memory
SFP Security Functional Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
SSH Secure Shell
SSL Secure Sockets Layer
ST Security Target
TDEA Triple Data Encryption Algorithm
TFTP Trivial File Transfer Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TRNG True Random Number Generator
TSF TOE Security Functionality
URL Universal Resource Locator
USB Universal Serial Bus
VLAN Virtual Local Area Network
VM Virtual Machine
VPN Virtual Private Network
Table 17 – Acronyms
Version: 2.0 Date: 18 July 2023 Page 56 of 60
9 ANNEX A – FORTIGATE MODELS,
GUIDES, ASIC/ENTROPY SOURCE AND
CPU
9.1 HARDWARE MODELS
Model Guidance Documentation / Firmware Filename ASIC CPU
FG-40F https://docs.fortinet.com/product/fortigate/hardware
FGT_40F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-40F-3G4G https://docs.fortinet.com/product/fortigate/hardware
FGT_40F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FWF-40F https://docs.fortinet.com/product/fortigate/hardware
FWF_40F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FWF-40F-3G4G https://docs.fortinet.com/product/fortigate/hardware
FWF_40F_3G4G-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-60E https://docs.fortinet.com/product/fortigate/hardware
FGT_60E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-60E-DSL https://docs.fortinet.com/product/fortigate/hardware
FGT_60E_DSL-v6-build9451-FORTINET.out
CP9lite SoC3
FG-60E-DSLJ https://docs.fortinet.com/product/fortigate/hardware
FGT_60E_DSLJ-v6-build9451-FORTINET.out
CP9lite SoC3
FG-60E-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_60E_PoE-v6-build9451-FORTINET.out
CP9lite SoC3
FWF-60E https://docs.fortinet.com/product/fortigate/hardware
FWF_60E-v6-build9451-FORTINET.out
CP9lite SoC3
FWF-60E-DSL https://docs.fortinet.com/product/fortigate/hardware
FWF_60E_DSL-v6-build9451-FORTINET.out
CP9lite SoC3
FG-60F https://docs.fortinet.com/product/fortigate/hardware
FGT_60F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-60F-3G4G https://docs.fortinet.com/product/fortigate/hardware
FGT_60F_3G4G-v6-build9451-FORTINET.out
CP9Xlite SoC4
FGR-60F https://docs.fortinet.com/product/fortigate/hardware
FGR_60F-v6-build9451-FORTINET.out
CP9lite SoC4
FGR-60F-3G4G https://docs.fortinet.com/product/fortigate/hardware
FGR_60F_3G4G-v6-build9451-FORTINET.out
CP9lite SoC4
FG-61E https://docs.fortinet.com/product/fortigate/hardware
FGT_61E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-61F https://docs.fortinet.com/product/fortigate/hardware
FGT_61F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FWF-60F https://docs.fortinet.com/product/fortigate/hardware
FWF_60F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FWF-61E https://docs.fortinet.com/product/fortigate/hardware
FWF_61E-v6-build9451-FORTINET.out
CP9lite SoC3
FWF-61F https://docs.fortinet.com/product/fortigate/hardware
FWF_61F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-80E https://docs.fortinet.com/product/fortigate/hardware
FGT_80E-v6-build9451-FORTINET.out
CP9lite SoC3
Version: 2.0 Date: 18 July 2023 Page 57 of 60
Model Guidance Documentation / Firmware Filename ASIC CPU
FG-80E-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_80E_PoE-v6-build9451-FORTINET.out
CP9lite SoC3
FG-80F https://docs.fortinet.com/product/fortigate/hardware
FGT_80F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-80F-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_80F_PoE-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-81E https://docs.fortinet.com/product/fortigate/hardware
FGT_81E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-81E-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_81E_PoE-v6-build9451-FORTINET.out
CP9lite SoC3
FG-81F https://docs.fortinet.com/product/fortigate/hardware
FGT_81F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-81F-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_81F_PoE-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-100E https://docs.fortinet.com/product/fortigate/hardware
FGT_100E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-100EF https://docs.fortinet.com/product/fortigate/hardware
FGT_100EF-v6-build9451-FORTINET.out
CP9lite SoC3
FG-100F https://docs.fortinet.com/product/fortigate/hardware
FGT_100F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-101E https://docs.fortinet.com/product/fortigate/hardware
FGT_101E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-101F https://docs.fortinet.com/product/fortigate/hardware
FGT_101F-v6-build9451-FORTINET.out
CP9Xlite SoC4
FG-140E https://docs.fortinet.com/product/fortigate/hardware
FGT_140E-v6-build9451-FORTINET.out
CP9lite SoC3
FG-140E-PoE https://docs.fortinet.com/product/fortigate/hardware
FGT_140E_PoE-v6-build9451-FORTINET.out
CP9lite SoC3
FG-200E https://docs.fortinet.com/product/fortigate/hardware
FGT_200E-v6-build9451-FORTINET.out
CP9 Intel
Celeron
G1820
FG-200F https://docs.fortinet.com/product/fortigate/hardware
FGT_200F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1627
FG-201E https://docs.fortinet.com/product/fortigate/hardware
FGT_201E-v6-build9451-FORTINET.out
CP9 Intel
Celeron
G1820
FG-201F https://docs.fortinet.com/product/fortigate/hardware
FGT_201F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1627
FG-300E https://docs.fortinet.com/product/fortigate/hardware
FGT_300E-v6-build9451-FORTINET.out
CP9 Intel i5-
6500
FG-301E https://docs.fortinet.com/product/fortigate/hardware
FGT_301E-v6-build9451-FORTINET.out
CP9 Intel i5-
6500
FG-400E https://docs.fortinet.com/product/fortigate/hardware
FGT_400E-v6-build9451-FORTINET.out
CP9 Intel i5-
8500
FG-401E https://docs.fortinet.com/product/fortigate/hardware
FGT_401E-v6-build9451-FORTINET.out
CP9 Intel i5-
8500
FG-401E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_401E_DC-v6-build9451-FORTINET.out
CP9 Intel i5-
8500
Version: 2.0 Date: 18 July 2023 Page 58 of 60
Model Guidance Documentation / Firmware Filename ASIC CPU
FG-500E https://docs.fortinet.com/product/fortigate/hardware
FGT_500E-v6-build9451-FORTINET.out
CP9 Intel i7-
6700
FG-501E https://docs.fortinet.com/product/fortigate/hardware
FGT_501E-v6-build9451-FORTINET.out
CP9 Intel i7-
6700
FG-600E https://docs.fortinet.com/product/fortigate/hardware
FGT_600E-v6-build9451-FORTINET.out
CP9 Intel i7-
8700
FG-601E https://docs.fortinet.com/product/fortigate/hardware
FGT_601E-v6-build9451-FORTINET.out
CP9 Intel i7-
8700
FG-1100E https://docs.fortinet.com/product/fortigate/hardware
FGT_1100E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E-2186G
FG-1100E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_1100E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
E-2186G
FG-1101E https://docs.fortinet.com/product/fortigate/hardware
FGT_1101E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E-2186G
FG-1800F https://docs.fortinet.com/product/fortigate/hardware
FGT_1800F-v6-build9451-FORTINET.out
CP9 Intel Xeon
W-3223
FG-1800F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_1800F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
W-3223
FG-1801F https://docs.fortinet.com/product/fortigate/hardware
FGT_1801F-v6-build9451-FORTINET.out
CP9 Intel Xeon
W-3223
FG-1801F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_1801F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
W-3223
FG-2000E https://docs.fortinet.com/product/fortigate/hardware
FGT_2000E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-1660v4
FG-2200E https://docs.fortinet.com/product/fortigate/hardware
FGT_2200E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6126
FG-2201E https://docs.fortinet.com/product/fortigate/hardware
FGT_2201E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6126
FG-2500E https://docs.fortinet.com/product/fortigate/hardware
FGT_2500E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-1650v3
FG-2600F https://docs.fortinet.com/product/fortigate/hardware
FGT_2600F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold
6208U
FG-2600F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_2600F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold
6208U
FG-2601F https://docs.fortinet.com/product/fortigate/hardware
FGT_2601F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold
6208U
FG-2601F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_2601F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold
6208U
FG-3300E https://docs.fortinet.com/product/fortigate/hardware
FGT_3300E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 5118
FG-3301E https://docs.fortinet.com/product/fortigate/hardware
FGT_3301E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 5118
FG-3400E https://docs.fortinet.com/product/fortigate/hardware
FGT_3400E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6130
FG-3400E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_3400E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6130
Version: 2.0 Date: 18 July 2023 Page 59 of 60
Model Guidance Documentation / Firmware Filename ASIC CPU
FG-3401E https://docs.fortinet.com/product/fortigate/hardware
FGT_3401E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6130
FG-3401E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_3401E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6130
FG-3600E https://docs.fortinet.com/product/fortigate/hardware
FGT_3600E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6152
FG-3600E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_3600E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6152
FG‐3601E https://docs.fortinet.com/product/fortigate/hardware
FGT_3601E-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6152
FG-3960E https://docs.fortinet.com/product/fortigate/hardware
FGT_3960E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2650V4
FG-3960E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_3960E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2650V4
FG-3980E https://docs.fortinet.com/product/fortigate/hardware
FGT_3980E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2680V4
FG-3980E-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_3980E_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2680V4
FG-4200F https://docs.fortinet.com/product/fortigate/hardware
FGT_4200F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4200F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_4200F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4201F https://docs.fortinet.com/product/fortigate/hardware
FGT_4201F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4201F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_4201F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4400F https://docs.fortinet.com/product/fortigate/hardware
FGT_4400F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4400F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_4400F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4401F https://docs.fortinet.com/product/fortigate/hardware
FGT_4401F-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-4401F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_4401F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
Gold 6248
FG-5001E https://docs.fortinet.com/product/fortigate/hardware
FGT_5001E-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2690v4
FG-5001E1 https://docs.fortinet.com/product/fortigate/hardware
FGT_5001E1-v6-build9451-FORTINET.out
CP9 Intel Xeon
E5-2690v4
FG-6300F https://docs.fortinet.com/product/fortigate/hardware
FGT_6300F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6300F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_6300F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6301F https://docs.fortinet.com/product/fortigate/hardware
FGT_6301F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6301F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_6301F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6500F https://docs.fortinet.com/product/fortigate/hardware
FGT_6500F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
Version: 2.0 Date: 18 July 2023 Page 60 of 60
Model Guidance Documentation / Firmware Filename ASIC CPU
FG-6500F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_6500F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6501F https://docs.fortinet.com/product/fortigate/hardware
FGT_6501F-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
FG-6501F-DC https://docs.fortinet.com/product/fortigate/hardware
FGT_6501F_DC-v6-build9451-FORTINET.out
CP9 Intel Xeon
D-1567
Table 18 - Hardware Models, Guides, ASIC/Entropy Source and CPU
9.2 VIRTUAL MODELS
Model Guidance Documentation / Firmware Filename Entropy
FortiGate-VM01 https://docs.fortinet.com/cloud-solutions/vmware-esxi
FGT_VM64-v6-build9451-FORTINET.out
Token via
USB pass-
through
FortiGate-VM02
FortiGate-VM04
FortiGate-VM08
FortiGate-VM16
FortiGate-VM32
FortiGate-VMUL
Table 19 - Virtual Models, Guides and Entropy Source